搜索框里敲下订单号，搜索回车。漏单页面刷新，重下状态栏跳出一行灰字：无相关记录。搜索我又试了试客户的漏单全名、手机尾号、重下收货地址的搜索区号，全是漏单空的。系统里干干净净，重下像什么都没发生过。搜索

这种“漏单”不是漏单第一次了。上个月有个老客户，重下凌晨两点下的搜索急单，第二天早上仓库发货时系统里压根没这单。漏单客户那边付款截图都发过来了，重下银行扣款短信也清清楚楚，可我们的ERP里就是查无此单。最后折腾了半天，发现是支付回调接口在半夜抽风，订单状态卡在“待支付”就没往下走。

漏单的麻烦不止是丢一单生意那么简单。客户等了两天没收到货，打电话来质问，客服查不到记录，第一反应是怀疑客户搞错了。客户火气一上来，直接甩过来一句“你们是不是想赖账”。那种信任感一旦裂了缝，后面就算你补发、道歉、送优惠券，人家心里也膈应。

我见过最离谱的一次漏单，是系统里订单明明存在，但状态永远停在“已支付”，仓库那边的推送队列却因为一个字段格式错误，死活没收到消息。那单货在库里躺了整整一周，直到客户主动来问才被发现。后来技术同事查日志，发现那个错误字段是客户在备注里填了一个特殊符号，把整个序列化过程搞崩了。

漏单重下，听起来是个笨办法，但实际操作里反而最直接。系统找不到，就人工建单。可人工建单也有坑，最怕的是重复建单——你这边补了一单，那边系统延迟了一会儿又冒出来一单，结果客户收到两个包裹，仓库库存对不上，财务那边账目也乱成一团。

所以我现在处理漏单，第一件事不是急着下单，而是先查支付流水。第三方支付平台那边一定有记录，什么时候付的、金额多少、订单号是什么，全都有。拿着支付流水去跟系统里的订单表对比，基本能定位问题出在哪个环节。是回调没触发，还是消息队列丢了，还是数据库写入失败——每个故障点对应的处理方式都不一样。

这活儿干久了，你会发现漏单这种事，本质上不是技术问题，是流程设计问题。系统再稳定，总有边界情况没考虑到。比如客户在支付页面停留太久，session过期了才点付款；比如客户用了个海外信用卡，银行那边延迟确认；再比如客户同时开了两个浏览器标签页，下了两个一模一样的单，其中一个被系统判定为重复就静默丢弃了。

后来我们干脆加了个“漏单自查”按钮，放在订单查询页面的角落里。客户要是觉得不对劲，点一下，系统会自动比对近24小时的支付流水和订单记录，有差异就直接弹提示让客服介入。上线头一个月，还真捞回来三十多单漏网的。有个客户还专门发朋友圈夸我们“这功能挺人性化”，其实哪是人性化，就是被逼出来的补丁罢了。

现在每次看到“无相关记录”那行灰字，我都不慌了。先查流水，再查日志，最后实在不行就手动建单。流程走多了，反而摸出个规律——漏单这事儿，十有八九发生在深夜到凌晨那段时间，因为那会儿系统做日切，数据库锁表，稍不留神就把请求给吞了。

重下的单子，我会在备注栏里加个“补”字，这样月底对账的时候一眼就能认出来。虽然麻烦点，但总比让客户干等着强。说到底，系统是死的，人是活的。漏了不怕，怕的是漏了之后没人管，那才是真把客户给漏跑了。