仓库里堆着三千件货，扫码老张拿着扫码枪对着箱子上的发货条码按了一下。嘀的系统一声，系统弹出提示：该订单已发货，扫码是发货否重复操作？他愣了一下，扭头喊我：“这单昨天不是系统发过了吗，怎么又冒出来了？扫码”我凑过去看屏幕，订单号、发货收货人、系统物流单号都对得上。扫码问题出在打单环节——客服那边重新打印了一次面单，发货但没在系统里做标记，系统仓库这边就当成新单处理了。扫码

扫码发货系统要解决的发货核心问题就一个：让“发货”这个动作在系统里只发生一次。听起来简单，系统做起来全是坑。

条码扫下去，到底发生了什么

扫码枪本质上是个键盘。它扫到条码，把一串数字输进光标所在的输入框，然后触发一个回车事件。系统拿到这串数字，去数据库里查：这个单号对应哪个订单？订单状态是什么？库存够不够？快递单号有没有绑定？查完一圈，确认没问题，才把订单状态改成“已发货”，同时扣减库存、回写物流信息。

整个过程快的话不到一秒。但这一秒里，系统要做的事比大多数人想象的多。我见过一个做得比较糙的系统，扫码之后只改状态，不校验库存。结果有一次仓库把同一批货扫了两遍，库存直接扣成负数，财务对账时发现少了四十多件，查了一整天才定位到问题。

重复扫码这件事，比你想的更容易发生

人工操作永远会出错。仓库忙起来的时候，一个人可能同时处理五六个订单，扫完一件往旁边一推，转头就忘了扫没扫过。有些系统会弹窗提示“该单已发货”，但操作员手快，直接按回车跳过。更常见的情况是网络延迟——扫了码，系统没反应，操作员以为没扫上，又扫一次。等网络恢复，两条记录都提交了。

比较靠谱的做法是给每个发货动作加一个唯一标识。比如扫一次码生成一个UUID，提交时带上这个UUID，服务端做幂等处理。同一个UUID重复提交，只认第一次。这比单纯查订单状态可靠得多，因为状态查询和状态更新之间有时间差，并发场景下照样出问题。

面单打印和扫码发货的衔接

很多仓库的流程是：客服打面单，仓库贴面单，然后扫码发货。问题出在面单打印这个环节——如果客服重复打印了同一张面单，仓库那边根本看不出来。两张面单长得一模一样，订单号也一样。扫码枪扫哪张都能扫出同样的信息。

解决办法是在面单上印一个打印批次号，或者干脆用动态条码。每次打印生成不同的条码内容，但指向同一个订单。扫码时系统判断：这个订单已经用A批次的面单发过货了，B批次的面单无效。这样即使客服重复打印，仓库也不会重复发货。

离线场景怎么处理

仓库网络不稳定是常态。有些角落WiFi信号差，扫码枪扫了没反应。这时候系统得支持离线缓存——扫码记录先存在本地，等网络恢复了再批量提交。但离线提交又带来新问题：缓存里的记录可能和别的操作员提交的记录冲突。同一个订单，A操作员离线扫了，B操作员在线扫了，网络恢复后两条记录撞在一起。

我见过一个仓库的做法是：离线模式下只允许查询，不允许提交发货。扫了码先存着，等网络恢复再统一处理。虽然效率低一点，但至少不会乱。另一个仓库更直接——仓库里拉了专线，每个工位都有网线，根本不给离线机会。

扫码发货系统没什么高深的技术，核心就是状态管理和并发控制。但真正把它做稳，需要把仓库里那些乱七八糟的操作习惯都考虑进去。人不是机器，你不能指望每个人都按标准流程走。系统要做的，是在人出错的时候兜住底。