# 扫码入库同一箱货被记两次，该按什么顺序核对去重键

- Link: https://www.itor.cn/656.html
- Published: 2026-10-17T23:34:07+08:00
- Author: it

仓库里经常出现这样的情形：一箱货刚扫完码，系统显示入库成功，操作员转身去搬下一箱，
回来一查记录，同一箱货却出现了两条。很多人的第一反应是操作员手快扫了两遍，但真正
排查下去，重复提交往往并不是人的问题，而是整条链路缺少一个稳定的去重依据。同一个
动作在不同环节被记录了两次，系统却没有能力判断这其实是同一件事。

先分清重复是从哪来的

重复记录的来源大致有三类，排查入口完全不同。第一类是网络重试，扫码终端提交后没有
收到响应，系统自动重发，服务端两次都做了处理。第二类是页面重复点击，按钮没有锁定，
操作员以为没成功又点了一次。第三类是多设备并发扫描，两台终端几乎同时扫同一箱货，
各自提交了一条。这三类的共同点是请求看起来都合法，区别在于重复发生在客户端、传输
层还是服务端并发环节。不先分清来源，直接改代码很容易改错地方。

去重键的选取要有先后顺序

去重键选得对不对，决定了后续所有措施是否有效。建议按业务单号、箱码、时间窗口、设备
标识的顺序逐层判断。业务单号是最稳的依据，一单货对应一次入库动作，天然唯一。箱码
次之，同一箱货在同一个入库批次里不应重复出现。时间窗口只能作为辅助，因为单纯靠时间
戳判断很容易误判，比如两箱不同货物在几秒内先后扫码，时间接近但业务上完全合法，用
时间窗口去重反而会把正常记录拦掉。设备标识适合用来区分并发来源，但不适合作为主键。
原则是优先用业务上天然唯一的字段，时间戳只做兜底。

四层防护是否各司其职

前端按钮锁定解决的是重复点击，请求发出后按钮置灰或加 loading 状态，能挡掉一部分人为
重复。请求幂等标识解决的是网络重试，每次提交带一个唯一标识，服务端识别到相同标识
直接返回上次结果。服务端唯一约束是最后一道防线，数据库对业务单号或箱码加唯一索引，
重复写入直接失败。异步队列消费则要防止消息被重复投递后二次写入，消费端需要做幂等
处理。这四层任何一层缺失，重复就可能漏过去。常见情况是前端锁了按钮，但网络重试没
做幂等，或者数据库有唯一索引但队列消费绕过了它。

一份可执行的核对清单

排查时按这个顺序走：先看日志里同一个业务单号对应的请求出现了几次，判断重复发生在
提交阶段还是写入阶段；再确认数据库唯一索引是否真实生效，有些表建了索引但字段允许
为空，重复数据照样能进；最后检查补偿任务和异步队列，看是否有重试机制在失败后二次
写入。三步走完，基本能定位重复发生在哪一层。

处理原则是先定位再动手

重复提交不是单一原因造成的，加锁、加唯一约束、改交互分别对应不同层的问题。先弄清楚
重复发生在客户端、传输层还是服务端写入环节，再决定用哪种手段。一上来就改代码，往往
只是把问题从一个入口堵到了另一个入口。it数运在处理这类企业数字化问题时，通常也是
先梳理链路再动方案，把技术问题说明白，后续维护才不至于反复。