先说结论：快递面单丢单，十有八九不是承运商的问题，是 WMS 和面单接口之间的链路自己把单子吃掉了。排查别从承运商查起，按这个顺序查：WMS 发单 → 接口队列 → 承运商返回 → 状态回写 → 打印。单子在哪一环停了，问题就在哪一环。顺序错了，你查三天也查不出来。
为什么单子会"凭空消失"
一个面单请求从 WMS 出来到贴上包裹，要走五道环节：
- WMS 生成发货请求；
- 接口层（或中间件）把请求发给承运商 API；
- 承运商返回面单数据和运单号；
- WMS 把运单号回写到订单，状态推到"待打印"；
- 打包台打印面单，工人贴单发货。
五个环节，每个都能吃掉订单：请求没发出去、队列里堵着没人消费、承运商返回了但你这边超时没收到、回写失败、打印机离线。报错的那种其实好办，至少你能看见。真正要命的是"静默失败"：WMS 觉得自己发了，承运商觉得自己没收到，订单卡在两个系统中间，哪个系统都不认它。这就是为什么仓库天天喊"丢单"，IT 查日志却说"一切正常"。
这个坑我见过三次：两个真实翻车现场
第一次，去年 11 月，华东一家做服装的 3PL 仓，对接 UPS 面单接口。仓库每天固定丢 20～30 单，承运商一口咬定他们后台根本没收到请求。查了一下午，根因在接口层：开发把请求超时设成了 5 秒，促销季承运商 API 响应慢到 8～10 秒，每次超时 WMS 就标记"面单失败"，但承运商那边其实已经生成了面单和运单号。两边各说各话：WMS 里单子是"失败"状态等着人工重打，承运商账上已经扣了面单费用。更惨的是，仓库看单子"失败"就点重试，重试成功后同一单冒出两个运单号，包裹贴哪个都有风险——贴错了就是丢件+客诉二连击。
第二次，今年 3 月，华南一家跨境电商仓，对接某国际快递接口。每天半夜 0 点到 2 点的单子批量"失踪"，白天一切正常。这个更阴：承运商 API 每天凌晨有维护窗口，返回的是"服务不可用"；而 WMS 的接口层根本没有失败队列——请求失败就直接丢了，不重试、不告警、不留记录。凌晨那两个小时的单子，系统里连条失败记录都没有，订单状态还停在"待打单"，仓库以为是系统卡了，傻等到天亮。查日志才发现，整整两小时的请求连发出去的机会都没有，直接在接口层被吞了。
两次翻车，根因其实是一个：面单链路没有"全链路对账"。钱和货都有人对，面单这一环没人对。
分步做法：五环排查链路
下面这份是我的上线前夜 checklist，要求客户逐项打勾，少一项都不许上线。
第 1 步：先看 WMS 的发单日志。 确认每个待发订单都有"发单请求"记录，请求里带订单号、包裹重量尺寸、服务产品。如果订单在 WMS 里连请求都没生成，问题在 WMS 内部（比如订单状态机卡住了、发单定时任务挂了），别去查接口，查了也是白查。
第 2 步：查接口层的请求队列。 异步发的，看队列积压长度、消费者进程是否活着、死信队列里有没有消息；同步发的，看超时设置和重试策略。超时时间不能小于承运商 SLA 承诺的响应上限，大促期间再加一倍余量——上面服装仓的 5 秒超时，就是在这一步被揪出来的。
第 3 步：查承运商返回。 每个请求必须有"请求—响应"配对日志：几点几分发了什么、返回了什么、运单号是多少。只记请求不记响应，等于没记。我见过最离谱的系统，日志只记"调用成功"四个字，连返回的运单号都不存，出事之后想对账都没得对。
第 4 步：查状态回写。 承运商返回运单号之后，WMS 必须把运单号写回订单，并把状态推到"待打印"。回写失败必须进重试队列，不能静默跳过。回写是丢单的重灾区——很多系统的请求和回写是两个独立事务，请求成功了，回写挂了，单子就悬空了：承运商有单，WMS 没单。
第 5 步：查打印。 打包台打印机离线、缺纸、驱动崩了，面单打不出来，工人通常会点"重新打印"。重新打印必须走"补打"流程（用已有的运单号重新出纸），不许重新请求新面单，否则一单一号变成一单两号，月底对账有你哭的。
第 6 步：做全链路对账。 每天截单后跑一遍四方对账：WMS 发单数 = 接口层请求数 = 承运商返回成功数 = 已打印数。四个数字对不上，差的就是丢的单。这个对账脚本，上线第一天就要有，不能等丢单了再写——丢单的时候再写，你连"丢了多少"都说不清。
第 7 步：幂等键。 每个面单请求必须带全局唯一的幂等键。推荐用"订单号 + 包裹序号"，不要用纯订单号——一单多包裹会撞键。承运商侧和自己的接口层都要按幂等键去重。这是防止"重试打出重单"的唯一办法，没有之一。
| 环节 | 典型症状 | 排查动作 |
|---|---|---|
| WMS 发单 | 订单一直"待打单"，无请求记录 | 查订单状态机、发单定时任务 |
| 接口队列 | 延迟越拖越高、死信队列堆积 | 查消费者状态、队列深度告警 |
| 承运商返回 | 超时多、偶发失败 | 核对超时参数、看承运商状态页、查配对日志 |
| 状态回写 | 有运单号但订单状态没变 | 查回写事务、重试队列 |
| 打印 | 工人说"打不出来" | 查打印机状态、走补打流程不重发请求 |
常见翻车点（上线前逐项自查）
- 超时设太短，促销季必爆。这个坑我见过三次，每次都是"平时好好的，一到大促就丢单"。
- 失败不进队列，直接丢。凌晨维护窗口、承运商偶发报错，都会变成"查无此单"。
- 重试不带幂等键。重试一时爽，月底对账火葬场——重复面单的费用，承运商照收不误。
- 只对钱和货，不对面单。财务对得上、库存对得上，面单少了几十张没人发现，直到客户投诉没收到货。
- 把"调用成功"当成"面单成功"。接口返回成功不代表面单生成了，要看返回体里的业务状态码，HTTP 200 里面包着业务失败，是承运商 API 的常规操作。
一个反常识的判断
丢单问题里，最危险的形态不是报错，而是"假装成功"。报错至少会触发告警，会有人去看；"请求发出去了、WMS 显示成功了、承运商没收到"，这种三不管状态能潜伏好几周，攒到大促当天集中爆发。防的办法只有一条：永远以承运商返回的运单号为准，不要以"我发了请求"为准。没有运单号的单子，一律视为没发出——这个口径要在上线前就跟仓库和客服对齐，不然出事之后三方扯皮，IT 背锅。
还有一个 trade-off 得说清楚：同步调用还是异步队列？同步简单，工人点打单立刻知道结果，但承运商一慢全仓库都在等，一个超时能卡住一条打包线；异步吞吐高、能削峰，但链路变长，排查难度翻倍。我的建议：日单量 5000 以下用同步 + 短超时 + 失败进人工处理队列；5000 以上必须异步，但异步的前提是上面的全链路对账和告警全部做到位。异步不是银弹，异步只是把"当场报错"变成了"事后对账"——对账做不到位，异步丢单比同步更难查。
面单接口这种东西，平时看着岁月静好，出事都是在大促当天凌晨三点。把这份 checklist 打印出来，贴在打包台旁边，比什么监控大屏都管用。
作者：林晓｜WMS 实施顾问
