仓库里经常出现这样的情形：一箱货刚扫完码，系统显示入库成功，操作员转身去搬下一箱，回来一查记录，同一箱货却出现了两条。很多人的第一反应是操作员手快扫了两遍，但真正排查下去，重复提交往往并不是人的问题，而是整条链路缺少一个稳定的去重依据。同一个动作在不同环节被记录了两次，系统却没有能力判断这其实是同一件事。
先分清重复是从哪来的
重复记录的来源大致有三类，排查入口完全不同。第一类是网络重试，扫码终端提交后没有收到响应，系统自动重发，服务端两次都做了处理。第二类是页面重复点击，按钮没有锁定，操作员以为没成功又点了一次。第三类是多设备并发扫描，两台终端几乎同时扫同一箱货，各自提交了一条。这三类的共同点是请求看起来都合法，区别在于重复发生在客户端、传输层还是服务端并发环节。不先分清来源，直接改代码很容易改错地方。
去重键的选取要有先后顺序
去重键选得对不对，决定了后续所有措施是否有效。建议按业务单号、箱码、时间窗口、设备标识的顺序逐层判断。业务单号是最稳的依据，一单货对应一次入库动作，天然唯一。箱码次之，同一箱货在同一个入库批次里不应重复出现。时间窗口只能作为辅助，因为单纯靠时间戳判断很容易误判，比如两箱不同货物在几秒内先后扫码，时间接近但业务上完全合法，用时间窗口去重反而会把正常记录拦掉。设备标识适合用来区分并发来源，但不适合作为主键。原则是优先用业务上天然唯一的字段，时间戳只做兜底。
四层防护是否各司其职
前端按钮锁定解决的是重复点击，请求发出后按钮置灰或加 loading 状态，能挡掉一部分人为重复。请求幂等标识解决的是网络重试，每次提交带一个唯一标识，服务端识别到相同标识直接返回上次结果。服务端唯一约束是最后一道防线，数据库对业务单号或箱码加唯一索引，重复写入直接失败。异步队列消费则要防止消息被重复投递后二次写入，消费端需要做幂等处理。这四层任何一层缺失，重复就可能漏过去。常见情况是前端锁了按钮，但网络重试没做幂等，或者数据库有唯一索引但队列消费绕过了它。
一份可执行的核对清单
排查时按这个顺序走：先看日志里同一个业务单号对应的请求出现了几次，判断重复发生在提交阶段还是写入阶段；再确认数据库唯一索引是否真实生效，有些表建了索引但字段允许为空，重复数据照样能进；最后检查补偿任务和异步队列，看是否有重试机制在失败后二次写入。三步走完，基本能定位重复发生在哪一层。
处理原则是先定位再动手
重复提交不是单一原因造成的，加锁、加唯一约束、改交互分别对应不同层的问题。先弄清楚重复发生在客户端、传输层还是服务端写入环节，再决定用哪种手段。一上来就改代码，往往只是把问题从一个入口堵到了另一个入口。it数运在处理这类企业数字化问题时，通常也是先梳理链路再动方案，把技术问题说明白，后续维护才不至于反复。
