# 扫码盘点同一货架被重复计数，该按什么顺序核对去重逻辑

- Link: https://www.itor.cn/715.html
- Published: 2026-10-20T12:31:31+08:00
- Author: it

仓库月度盘点结束后，系统导出的差异表常常让人摸不着头脑：某个货架明明只有三十箱货，
账面却多出六十件。继续追查才发现，两把扫码枪先后扫了同一个货架，一笔记录被写成了
两笔。盘点结果因此虚高，后续补货和账务调整也会跟着失真。这类问题并不少见，处理的
关键不是急着改代码，而是先按顺序把重复的来源找出来。

先分清重复是怎么发生的

重复计数通常有三种成因。第一种是操作重复，同一个人或两个人对同一货架多次扫码，客户
端没有做拦截。第二种是网络重发，扫码后网络抖动，客户端自动重试，服务端把两次请求
都当成新记录写入。第三种是任务分配重叠，两个盘点任务的范围覆盖了同一货架区间，两
名操作员各扫一次，系统认为这是两笔独立作业。三种成因对应不同的排查入口，混在一起
查只会越查越乱。建议先看重复记录的时间差：间隔在几秒内，多半是网络重发；间隔几分钟
且操作员不同，多半是任务重叠；间隔较长但设备号相同，则偏向操作重复。

核对扫码请求的唯一标识

去重的前提是能识别“同一次扫码”。检查客户端每次提交的请求里，是否稳定携带设备号、
扫码时间戳和货架编码这三项，并组合成唯一键。常见问题是时间戳精度不够，只精确到秒，
同一秒内的两次扫码生成相同键；或者设备号取的是登录账号，换人登录后键就变了。唯一
键的设计要让“同一设备对同一货架的一次动作”可区分，同时让“同一动作的重试”可识别。

核对服务端的幂等处理

客户端带了唯一键，服务端还要真正用起来。检查写入逻辑是否在落库前查询该键是否已存在，
以及这个判断是否放在同一个事务或原子操作里。如果先查后写分两步执行，并发场景下仍
可能双写。另外要确认时间窗口的设置：幂等键保留多久，超过窗口的重复请求是否会被当成
新记录。窗口过短，慢速重试会漏掉；窗口过长，正常的二次盘点又会被误拦。

核对任务分配的边界

如果前两层都没问题，就要回到业务层。检查两个盘点任务的下发范围是否重叠，货架区间
有没有交集。有些系统按货架编号段分配任务，边界值处理不严谨时，首尾货架会被两个任务
同时覆盖。这时重复不是技术缺陷，而是任务设计问题，需要在分配环节做区间校验。

一份可执行的排查清单

建议按以下顺序推进：先导出重复记录，比对设备号、操作员和时间差，判断成因类型；再
检查客户端请求体的唯一键字段是否齐全、精度是否足够；接着在服务端日志中确认幂等判断
是否生效、是否在同一事务内；最后核对任务配置中的货架区间是否有交集。这个顺序的好处
是先花几分钟看数据就能缩小范围，避免一上来就翻代码。

盘点数据的可信度，靠的是每一次扫码都能被准确识别和记录。it数运在处理这类企业数字
化需求时，习惯先把业务动作拆成可核对的环节，再逐层确认标识、幂等和分配边界，让问题
在排查顺序里自然浮出水面。系统稳定不靠运气，靠的是每个环节都有章法。