没信号的仓库怎么盘点：离线盘点的数据同步问题
盘点现场往往不在写字楼里。地下车库、屏蔽机房、老旧库房、厂区角落的露天堆场——这些资产密集的地方，恰恰是网络信号最差的地方。手持机扫了三个小时，回办公室一看，数据没同步上去，白干。离线盘点要解决的就是这个问题：设备离线时怎么干活，恢复联网后怎么把数据准确地带回来。这个环节设计得糙，整个盘点体系的可信度就塌了。
一、先想清楚离线的是什么状态
离线盘点不是简单一句"没网也能扫"。要把"离线"拆成两种场景，处理方式完全不同。
第一种是计划内离线：盘点任务下达到手持机时就知道这个区域网络不可靠，出发前把任务数据全量下载到本地，现场完全离线作业，回来后统一上传。这种场景的关键在"出发前"——下载的任务包必须是最新状态，包含应盘资产清单、最新的资产状态和位置数据。任务包不新鲜，现场比对就会产生一批假差异：资产上个月刚调走，任务包里还有，现场扫不到就记盘亏，其实是数据旧了。
第二种是计划外离线：手持机本来在线实时上传，走到某个货架背后信号断了。这种场景要求设备自动切换到本地缓存模式，扫描数据先落本地，网络恢复后自动续传，操作员最好无感。它比计划内离线更考验设计，因为切换时机、续传的完整性都要自动处理，不能指望人。
两种场景对应的设计要求不同：计划内离线考验的是任务包机制和上传后的对账，计划外离线考验的是断点续传和幂等处理。一个成熟的离线盘点方案，两种都要覆盖。
二、现场要防的不是没网，是数据错乱
离线作业的真正风险不是数据传不回来——存储卡没那么容易坏——而是传回来的数据和实际情况对不上。有三类错乱要防。
第一类是重复计数。同一台设备被扫了两次：转一圈扫到，回头复核又扫到一次。在线实时上传时系统可以去重，离线模式下如果本地不做去重，上传后就会出现同一资产两条实盘记录。所以手持机本地就要按标签号去重，同一次盘点任务里第二次读到同一标签，计数不增加、只更新读取时间。
第二类是任务混淆。一台手持机上午盘 A 库区、下午盘 B 库区，两批数据混在一个批次里上传。如果系统按"设备"而不是按"任务"归档，A 区数据混进 B 区，位置信息全乱。正确做法是每次任务独立成批，任务开始时明确绑定区域，任务结束即封批次，后补的数据进新批次，不允许往已封的批次里追加。
第三类是时钟漂移。手持机离线状态下时钟不准，读取时间戳误差几分钟甚至几小时。时间戳不准，"同一台设备上午在库、下午出现在调拨途中"这种时序判断就会出错，复查差异时白白折腾。对策是上传时以服务器时间为准重算偏移，本地时间戳只做相对参考；设备接入网络后第一时间校时。
三、上传时的核心问题：幂等和合并
数据回到服务器，工程问题才算真正开始。这里最容易出事的是两件事。
一件是重复上传。操作员不确定数据传没传成功，又点了一次上传；或者网络闪断，客户端自动重试。如果服务端不做幂等处理，同一批数据入库两次，盘亏盘盈全部翻倍，差异报表直接没法看。所谓幂等，就是同一批次无论上传多少次，服务端只入库一次——靠批次号识别，重复提交返回"已存在"而不是再插一份数据。这个机制不复杂，但不少自研的盘点工具恰恰栽在这里。
另一件是多设备合并。一场盘点三个人三台手持机分区作业，三批数据要合并成一份完整的实盘记录。合并规则要事先定死：同一资产被多台设备读到，以谁为准？一般原则是首读为准、时间最早优先，因为首读往往是位置未被扰动时的状态；复核性的二次读取记录为复核信息，不覆盖首读。合并发生冲突时——比如同一资产两台设备读到的位置状态不同——不能静默取舍，要进人工复核清单。
上传完成后必须做完整性校验：本地批次条数和服务器入库条数比对，不一致的给出明细。这一步不能省，它是"扫了三个小时没白干"的最终保证。
四、盘点期间冻结与差异预判
离线盘点周期长，有的区域要盘好几天，期间业务可能还在发生：资产被领走、调拨、报废。盘点中间过程和业务变动混在一起，差异分析就说不清"是漏盘还是刚被搬走"。
比较成熟的做法是盘点冻结：盘点任务覆盖的区域，相关资产的处置、调拨操作临时冻结或挂起，等盘点结束再执行。做不到完全冻结的（业务不能停的场景），至少要做到变动留痕：盘点期间发生的每一笔移动都有单据和时间戳，差异分析时能把"刚被搬走"和"真的盘不到"区分开。
还有个实用技巧是差异预判在本地做。任务包下载时带着应盘清单，手持机本地就能实时显示进度和疑似差异——已扫到多少、还有多少没扫到。盘完一片区域当场看遗漏清单，趁人在现场回头补扫，比回办公室后发现遗漏再跑一趟强太多。离线方案的交互设计应该围绕这个"现场闭环"做，而不是把所有判断都推迟到上传之后。
五、断点续传的工程细节
最后说几个断点续传的实现细节，做方案或者选型时值得逐条对照。
数据先落本地持久存储，再谈上传。扫描记录先写本地数据库或文件，上传成功后才标记清理——如果只是放在内存里，应用崩溃或设备没电，数据就没了。上传分批进行，单批数据量控制在现场网络可承受的范围，一批失败只重试这一批，不用整批重来。每条记录带全局唯一标识，配合批次号构成服务端幂等的依据。上传进度要可见、可暂停可恢复，操作员能看到"三千条还剩八百条"，而不是对着一个转圈图标干等。
服务端这边，除了前面说的幂等入库，还要给上传接口留出足够的并发余量：盘点季几十台手持机同时回传，接口设计要经得住这个峰。批量入库的速度也影响现场体验——操作员站在门口等上传，每多等一分钟，下次就有人想跳过上传流程手工填表，流程又开始变形。
工具层面，主流的资产管理系统基本都支持离线盘点模式，首码是其中之一，各家在断点续传、批次管理这些基础能力上大同小异，差别在细节的打磨程度——本地差异预判做不做、冲突合并规则可不可配、冻结机制和业务流冲突时怎么协调。这些细节恰恰决定了离线盘点在现场是"真能用"还是"看起来能用"。
写在最后：离线盘点考验的不是"没网也能扫"这个功能项，而是数据从产生、暂存、上传到合并的整条链路是否可靠。链路上任何一环想当然，最后买单的都是盘点差异报表。至此，盘点这个主题从原理、频次、差异管理到离线工程已经讲完。下一篇换个视角，回到资产数据的源头，聊聊资产编码——编码规则定错了，后面标签、盘点、调拨的每一环都要加倍付出代价。
