零基础开自动发货店，出错后从哪查

零基础开设自动发货店，遇到支付后不发卡、前台显示可买却提示无货源，很多人第一反应是重新上传商品或更换货源，但根源往往藏在交付链路里。下面以卡密类商品为例，给出一套能自行完成的排查顺序，重点在于区分订单结果、货源状态与访问权限，不凭单一现象下结论。

先从原订单入手核对交付结果

排查时必须以原订单为唯一依据，优先只读查询，不能在原因未明时重下订单。例如假设一笔卡密订单支付成功却没收到卡密，先不要凭通知记录判断已发卡，应该先在订单列表中定位该笔订单，再查询订单详情。核对交付状态、关联货源、返回结果和售后状态，确认是明确失败、已撤销，还是结果不确定。

如果订单日志显示渠道明确失败且未交付，属于可处理范围；如果订单状态正常但未发卡，问题通常出在货源或发货规则，不能直接补单。这个区分会直接影响后续动作，结果不确定时先保留原订单数据，走人工核查，避免卡密重复发放。

再核对货源绑定与库存类型

货源问题分两类，一类是绑定错误，一类是类型误配，处理方式完全不同。例如假设后台有充足卡密，订单却始终无货，先确认货源启用状态，再核对该货源是否绑定到正确商品或规格，不要只看总库存。卡密、卡号加卡密、固定卡密与充值货源用途不同，导入方式也存在差异。

接着确认有效可售数量，库存展示与可售数量不是同一条件，前台显示有货不代表当前规格具备可发卡量。若绑定和数量都正常，再检查选源策略，低价优先、自营优先、顺序轮询各有分配规则，不能以货源列表排序推断每一单必走某渠道，要根据当前配置核对。

最后排查前台访问与购买权限

前台不显示或不能下单，常见于状态、终端和权限不匹配。例如假设商品在后台存在，前台却看不到，先确认商品与规格的销售状态，再核对当前分类、显示限端和前台筛选条件，确认访问的是正确站点并已启用对应主题，不能只凭后台记录认定前台可售。

如果前台能展示但无法购买，需要区分库存和购买资格。前台库存展示与购买资格是两个条件，先核对规格绑定货源、有效库存、购买数量和渠道可用性，再检查用户下单权限、商品权限组、限购模板与商品级别限制。不要同时关闭全部限制，先定位具体命中项再调整。

用验收清单确认排查结果

完成三层排查后，按顺序核对结果：原订单结果明确，货源绑定与库存类型匹配，前台状态、终端和权限均满足。三者同时成立，才能认定问题已定位；若任一项仍异常，按对应层级继续核查，不跳过顺序。

把这次排查中确认的状态和调整项记录下来，下一次遇到同类问题，直接对照同一套顺序核实，先从原订单结果入手，再到货源与前台权限，即可快速缩小范围。

排查过程中有两项容易被忽略，直接影响判断准确性，需要单独确认。第一是商品订阅与变动状态，若商品没有正常订阅，后续订单可能无法稳定获取货源，接入时可调用 GET /goods/catalog?catalogRef=...&subscriptionState=subscribed 查询已订阅商品，页面未返回目标商品时，优先核对订阅配置，不要误以为货源缺失。

第二是 Webhook 的接收与保存，自动发货依赖回调结果，平台会在订单、卡密、退款等事件发生时发送请求，消息没有额外签名，收到后要先检查 JSON 格式与必填字段，保存 eventId，同一条消息重复收到时不得重复发卡，卡密要先安全保存再进入后续流程，响应正文需返回纯文本 OK，保存失败时不要标记订单已完成，直接调用订单查询接口核对当前真实状态。

参考资料：接入指南（2026-09-20）；商品前台不显示（2026-10-18）；库存与发货异常（2026-10-18）。具体操作与适用范围以对应文档为准。