面单打出来了，包裹却没出库？十有八九，单子丢在接口链路上了。
2023 年底大促季，一家洛杉矶的 3PL 仓找到我：旺季一天 1.2 万单，面单打印机哗哗地吐，可每天下班一对账，承运商实际揽收的件数总比系统里的出库数少 300 多票。客户投诉、退款、重新发货，一天烧掉小几千美金。查了一圈，拣选没问题、打印没问题——问题全在 WMS 和承运商面单接口之间的那条链路上。
先给结论：面单丢单，几乎不会死在"打印"这一环。真凶集中在三个地方：请求压根没发出去、超时重试搞出重复面单、以及根本没人做对账。下面这套排查链路，是我这些年对接过多家承运商面单接口后总结出来的，按顺序走，基本都能定位到。
先问一句：请求到底发没发出去
丢单最蠢的一种死法，是你的 WMS 压根没把请求发出去——或者发了、没回来，而你以为发了。
我排查的第一步永远是看本地请求日志。注意，不是看 WMS 里订单状态变没变，而是看出站网关的调用记录：这票订单，有没有一条"向承运商请求面单"的记录。没有这条记录，后面查接口文档、调超时参数全是白搭，问题在你们自己这头。常见的几种：消息队列的消费者挂了，队列越积越深没人消费；定时任务没起来；或者订单状态流转卡住了——比如 OMS 把订单推过来了，但 WMS 里还在等波次释放，面单请求压根没被触发。这种情况我见过不止一次，旺季一忙，波次策略配错了，几百票订单静静地躺在"待释放"里，面单请求连发都没发过。
还有一种更隐蔽的：请求发出去了，但日志没记全。有些系统只记成功不记失败，有些日志轮转策略太激进，出事那几分钟的记录已经被删了。我给客户的铁律是：面单接口的请求日志必须全量留痕——发了什么、什么时候发的、对方回了什么、耗时多少，一条都不能少。真到跟承运商对账吵架、或者客户索赔的时候，日志是唯一的证据。日志不全，神仙也帮你定位不了。
所以第一步的判断很简单：日志里没有这条请求，问题在你们自己这头，先修内部链路；有这条记录，再往下走。
另外给个建议：把面单请求的状态直接做到 WMS 订单详情页里——这票订单请求发了没、承运商回了什么、一共重试几次，打开订单一眼就能看到。很多仓的 WMS 订单页只显示"已打单/未打单"两个状态，出问题了还得翻日志翻队列，排查效率差了一大截。状态做细一点，省的是每次救火的时间。
超时重试最坑：网络断了，承运商那头可能已经建单了
这是我见过丢单最多的死法，也是最冤的一种。
场景是这样的：WMS 请求承运商面单接口，对方半天没回，超过了超时时间（各家承运商不一样，按承运商文档来），WMS 判定超时，自动重试。第二次请求成功，拿到面单，皆大欢喜——但第一次请求其实在承运商那边已经建单成功了，只是响应没回来。于是这票订单有了两张面单、两个追踪号。
后果有两个。第一，多付一份运费：有些承运商按建单收费，作废流程还特别麻烦，小仓根本没人去一单一单地作废，钱就这么悄悄漏掉了。第二，仓库只贴了一张面单出库，另一张成了"幽灵单"——系统里显示已建单，客户也能查到追踪号，但这个包裹永远不会有揽收记录。客服接到投诉一查：追踪号有效，就是没物流信息，完全摸不着头脑，最后只能认赔重发。最气人的是，这种单子你查 WMS 全是正常的，查承运商追踪也"正常"，两边都正常，货就是没走。
解法就两个词：幂等，和重试策略。
幂等，意思是面单请求必须带业务唯一键（比如订单号加包裹序号），承运商接口一般都支持"同一个键重复请求，返回同一张面单"。对接的时候一定要跟承运商确认这一条——有些接口默认不开幂等，得在签约或配置里单独申请。不确认这一条就上线重试，等于亲手给自己埋雷。签约谈判的时候就把这条写进去，别等出事了再去求人开。
重试策略，核心是超时之后别无脑重发。我的做法是：第一次超时，先调承运商的查询接口，用订单号或包裹信息确认对方到底建没建单——建了就直接拿现成的用，没建再重发。查一次的成本，远低于事后处理一堆幽灵单的成本。重试次数也要封顶，间隔拉开，别在对方系统抖动的时候火上浇油。大促期间承运商接口本来就慢，你这边无脑重试，只会把对方打得更慢，恶性循环。
还有个大促前的功课：上线新承运商接口之前，先做一轮超时压测。故意把超时时间设短、模拟网络抖动，看系统在超时风暴里会不会搞出重复面单。我见过太多系统平时跑得好好的，一到大促承运商接口一慢，幽灵单哗哗地冒。平时不测，大促就替你测，学费贵得多。
顺带说一句：打印环节反而很少丢单。面单打出来了没贴上、贴错包裹了，那是现场管理问题，调监控、查拣选记录就能定位，不在接口链路上。真正在接口链路上丢的单，十个里有九个死在"超时"这两个字上。
每天跑一次对账，兜住所有漏网之鱼
前两步是"出事了怎么查"，这一步是"怎么让出事立刻被发现"。
不管链路做得多健壮，我都坚持让客户每天跑一次对账任务，逻辑其实就三行：拉承运商侧的建单数（调对账接口或者下载账单），拉 WMS 侧的实际出库确认数，两边按订单号或追踪号一对，差集就是丢单。对账口径要注意三点：作废的单要剔除，不同承运商分开对、别把 A 家的单算到 B 家头上，对账时间点固定（我一般建议每天凌晨跑，避开承运商的结算窗口）。
告警阈值怎么设？我的经验：差集超过当天单量的 0.5% 就告警，超过 2% 直接打电话。别设成"有差异就报"——承运商偶尔有延迟建单，比如晚上批量结算，今天建的单明天才进账单，零容忍只会把人吵麻，最后真出事了反而没人看告警。阈值是拿来用的，不是拿来供着的，设得太敏感等于没设。
那家洛杉矶的 3PL，最后就是靠对账任务兜住的。对账跑起来之前，他们连"每天丢多少"都说不清——这才是最可怕的，连问题有多大都不知道。对账上线之后，丢单从每天 300 多票降到个位数，剩下的几票基本都是现场贴错单，跟接口没关系了。每天早上运营第一件事就是看对账报告，有差异当天就查，不让问题过夜。
对账差异出来之后，处理也要分类：延迟建单的等一天再看，幽灵单走作废流程，作废了但账单里还在收钱的找承运商要 credit。最关键的是指定一个人负责——对账报告没人看，等于没跑。我见过对账任务跑了半年、报告躺在邮箱里没人打开的，等于白跑。
排查面单丢单，记住这句口诀：先查日志发没发，再看超时建没建，三对打印贴没贴，天天对账跑一遍。
