自动发货多快算合格，按出码时延定标准

判断自动发货是否够快，取决于支付完成到用户拿到卡密的真实耗时，不能只看接入文档里的回调接口名或后台的一次通知展示。同一平台在低峰零散订单与高并发抢购场景下的表现并不一致，必须回到你实际会使用的订单规模来验证。下面从可观察的时间起点、分段阈值和验证方法展开。

合格速度的计时起点与终点

速度只需要测量一段，即从支付成功被系统确认，到用户端实际可见卡密或发货通知。只统计接口到接口的内部延迟没有意义，因为真实失败往往发生在卡密落库与流转换环节。查资料可知，自动发货链路中的异步消息包含 goods.ready、aftersale.message.created，退款结果集中在 order.changed，但这几个事件只说明状态变化发生，不直接等于用户已拿到货。你需要以用户完成支付并返回商城的页面，到卡密在订单页或消息里可完整复制作为判定区间。这样测出的数值才对应真实的交付速度，也能区分是平台出码慢还是通知推送、短信通道受外部影响。

分段时延的参照标准

行业里没有绝对通用的数值，但可以按三档判断。第一档是顺畅，指支付成功后多数卡密在数十秒内出现在用户侧，游客订单也不需要人工干预；第二档是可接受，在并发较高或第三方支付回调稍慢时，交付落在合理范围且状态可准确追踪；第三档是不合格，即超过可容忍时间，或卡密出现缺货、绑定失败却未在订单状态里明确体现。例如，测试环境里在一个小时内连续下十笔不同金额和关系的游客订单，若均能在预期时间内拿到可正常使用的卡密且没有红字提示，该速度就达到合格线。具体数值要以你的客群耐心为准，发货越直接、用户期待越短，阈值就越严。

把状态同步变成可核对的证据

不能只靠人工截图，要把查询接口与后台对账纳入速度判断。以订单详情查询接口作为核对工具，比直接盯着后台列表或跳转到第三方页面更可靠。每次测速时记录订单号、支付完成时刻、卡密首次可见时刻和事件出现次序，再核对事件流里是否先出现代表备货完成的消息，后出现发货提示。如果订单已创建但卡密状态迟迟不变，说明问题出在库存或生成环节，而不是用户操作。将每笔订单的这一组时间串起来，平均耗时和最大耗时才具备可比较性。若涉及外部渠道冷却或验证码链路，需要单独给这些环节设置不同的合格标准，避免把所有延迟都算到自动发货上。

在实测中验证并固化标准

测试前先确认平台在订单创建前是否需要订阅才能接收状态变化，再在真实会售卖的品类上构造订单。用统一支付方式连下十笔，覆盖普通账号和游客账号，记录每一次出码耗时。全部完成后，核对跳号、报错和延迟最大的样本，若最大耗时在业务可承受范围内且未出现丢单，即可将该数值定为本店合格线。保留测试记录，后续按月抽检并比对接口返回的事件顺序与后台显示是否一致，若有条件和平台支持，可在配置中开启订单通知，把店铺后台、接口和买家触达的时间统一对齐。这样，自动发货的速度就不再是看运气，而是一套可衡量、可复盘、可按季节与品类调整的操作标准。

参考资料：接入指南（2026-09-20）。具体操作与适用范围以对应文档为准。