# 仓库断网后PDA还能不能继续作业？离线缓存和数据补传怎么实现

原文：[https://www.rfidpda.cn/news/xinwen/2625.html](https://www.rfidpda.cn/news/xinwen/2625.html)

仓库Wi-Fi覆盖不稳时，PDA是否能继续收货、拣货、盘点，取决于系统有没有为离线状态设计本地任务、扫码记录、业务校验、补传和防重复机制。本文说明哪些操作适合离线、哪些必须等待服务器确认，以及如何用稳定业务标识、状态机、重试队列和人工异常处理，把断网后的数据安全补回系统，同时保留可追查记录。

![仓库WiFi中断时PDA把扫码记录暂存在本地队列的示意图](https://www.rfidpda.cn/uploads/allimg/20260716/1-260G6134Gb45.jpg)

断网时先把动作可靠记下来，而不是假装已经写进服务器。

**仓库PDA手持机断网后离线缓存与数据补传方案**：稳妥的思路，是把每次需要同步的业务操作写成一条独立记录。它至少要有本地操作编号、业务类型、关联单据、条码或对象标识、数量、操作人、设备、现场时间、创建顺序、当前同步状态和必要的业务上下文。字段不必盲目堆砌，但要足够让服务端重放和判断。

本地操作编号尤其重要。它不是数据库自增行号给人看，而是这次业务动作的身份。员工因为页面卡顿再次点击，应用因为超时重试，网络中间设备重复投递，只要它们属于同一动作，就应带着同一个编号。服务端据此识别“这是上次那一笔又来了”，而不是再做一遍。

离线记录应写入持久化数据库，并在一个本地事务里同时保存业务数据和同步队列状态。页面显示“已暂存”之前，写入必须成功。应用崩溃后重新打开，要能从本地数据库恢复待传记录；设备重启后，也要能继续补传。仅靠内存队列无法满足这个要求。

还要保存原始输入和必要的解析结果。比如员工扫到的是一个包装码，应用从中解析出物料、批次和数量。如果以后解析规则改变，只保存最终数量可能难以审计；只保存原始字符串又可能让补传时缺少当时业务上下文。哪些字段要留，应由业务追溯需要决定，而不是全存或全不存。

## 仓库系统提示要分状态！

仓库系统里，一个模糊的“提交成功”会带来很多误会。断网时数据只是保存在本机，页面却显示提交成功，员工自然会认为后台库存已经更新。下一班在另一台设备上看不到，就会怀疑系统丢数据。

更清楚的提示可以分成几种状态。操作写入本机后显示“已离线保存”，并告诉员工还有多少笔等待同步；服务器确认后变成“已同步”；业务校验失败则显示“需处理”，说明原因和处理入口。不同状态在颜色之外还要有文字或图标，避免员工只凭颜色判断。

状态变化应贴近任务，而不是藏在设置页深处。员工查看当前单据时，应该能看到这张单据还有几笔待传；班组长查看设备时，能看到待传总数和最早一笔时间；IT排查时，能进一步查看错误类型。三类人看到的信息层级不同，但数据来源应一致。

还要避免“转圈等结果”把现场困住。如果应用已经把操作可靠写入本地，就可以让员工进入下一笔，而后台负责发送。若业务要求必须等服务器校验，页面应明确说正在等待在线确认，而不是让员工猜这一枪要不要重扫。

提示音也要区分。条码读到、本地保存、服务器拒绝不能都用同一个短促声音。员工不可能一直盯屏幕，声音和震动是高频作业中的重要反馈。设计时可以把成功层级做得简单，但不能把失败和待确认混成成功。

## 补传不是“联网后把全部数据再发一遍”

网络恢复时，最直觉的做法是遍历本地记录逐条上传。真正上线后，还会遇到顺序、依赖、重试、限流和冲突。

同一业务链上的动作可能有前后关系。先收货，再上架；先创建容器，再装入明细；先绑定托盘，再移动托盘。如果补传时打乱顺序，服务端会收到一个尚不存在或状态不允许的对象。队列需要保留必要的先后关系，不能单纯谁文件小谁先传。

不同业务之间又不必全部串行。某张盘点单的一笔失败，不应拖住所有巡检记录。可以按单据、任务或业务对象分组，组内保持顺序，组间按服务能力适度并行。这里的并行不是越多越快，仓库一批设备同时恢复网络时，过猛上传会冲击无线网络和服务端。

重试也要有节奏。连接刚恢复时信号可能仍不稳定，如果每条记录连续重试，会耗电、占网，还可能让服务端收到密集重复请求。可靠后台任务通常会在网络满足条件时执行，失败后逐步延长重试间隔，并保留人工立即重试入口。业务拒绝和网络失败要分开：超时可以重试，单据已关闭则不能靠重试变成功。

补传过程中，应用退出或设备重启不应丢掉队列。后台任务需要以持久方式调度，而不是依赖某个页面一直打开。安卓应用可以借助系统推荐的持久后台任务机制配合本地数据库，但具体实现仍要按设备系统版本和应用架构验证。工具只能保证任务有机会继续执行，业务是否幂等、顺序是否正确仍由应用设计负责。

## 防重复要由服务端兜底

![PDA离线任务按待传成功失败三种状态管理的示意图](https://www.rfidpda.cn/uploads/allimg/20260716/1-260G6134I5351.jpg)

状态看得见，现场人员才知道哪些数据还没有完成。

设备端可以防止员工快速连点，也可以在按钮提交后暂时禁用，但这些只能减少重复，不能作为最终保证。超时场景最典型：PDA已经把请求发到服务器，服务器也写入成功，只是确认响应在返回途中断了。设备不知道结果，于是恢复网络后再次发送。若服务端每收到一次就扣一次库存，重复就发生了。

服务端应按本地操作编号或业务幂等键识别重复请求。同一编号再次到达时，不再重复执行业务写入，而是返回之前的处理结果。这个编号需要在设备初次创建操作时生成，并在所有重试中保持不变。若每次重试都新建编号，服务端看到的仍是不同操作。

幂等键的作用域也要设计。仅用条码作为键太粗，同一条码可能在不同单据、不同数量、不同时间被合法扫描多次；仅用时间戳又可能碰撞或因设备时钟偏差失真。更实用的键通常由稳定的操作编号配合租户、业务类型或设备范围组成，具体取决于系统的数据隔离方式。

服务端保存幂等结果时，还要考虑保留周期。待补传数据可能在设备上积压较久，如果服务端很快清掉去重记录，旧请求再次到达就会被当作新操作。保留多久，应覆盖业务允许的最长离线周期和异常恢复窗口，并结合数据量评估。

数据库层的不可重复约束可以再加一道防线。比如某业务动作的操作编号在记录表中只能出现一次。应用逻辑先判断，数据库约束兜底，两者配合比只在页面上禁按钮可靠。发生冲突时，服务端应返回已存在记录的状态，而不是把数据库错误直接丢给员工。

## 设备时间不能决定业务真相

离线数据通常会带两个时间：现场发生时间和服务端接收时间。两者都重要，但用途不同。

现场发生时间帮助还原员工什么时候扫描、在哪个班次操作。不过PDA时钟可能不准，也可能因为长期离线没有校时。它适合做业务线索，不宜单独决定所有先后和有效性。

服务端接收时间由中心系统记录，更容易统一，但它只表示数据什么时候到达。设备离线三小时后补传，接收时间会晚于实际作业。若报表只看接收时间，整个班次的工作会被挪到网络恢复之后。

因此，系统应同时保存两类时间，并在服务端用单据版本、操作序号、业务规则和接收顺序综合判断。需要严格排序的动作，可以由设备为同一任务生成递增序列，服务端检查缺口和逆序。不能只按手机时间排序，也不能简单按补传到达顺序覆盖旧值。

设备时钟还要纳入运维。MDM或系统时间同步可以减少偏差，但断网和手工改时仍可能发生。后台日志应记录时区、设备时间和服务端时间，出现跨日、跨班次异常时才容易定位。

## 冲突发生时，不要偷偷用“后写覆盖”

离线期间，服务端数据仍可能被其他人修改。员工下载任务时显示某货位有十箱，他离线后拣走八箱；与此同时，另一名在线员工完成了调拨。补传时，本地旧状态和服务端新状态冲突。

最省事的实现是后一次写入覆盖前值，但库存和单据场景里，这往往会掩盖问题。后到的数据未必更正确，它只是更晚到服务器。离线记录还可能是几个小时前发生的动作。

更安全的方式是带上读取时的业务版本或单据版本。服务端收到更新时，先判断当前版本是否仍匹配。匹配则按规则处理，不匹配则进入冲突状态，由系统尝试可解释的合并，或交给有权限的人复核。

哪些冲突能自动合并，要按业务定义。两个盘点观察值可以都保留，供差异分析；两个对同一序列号的出库占用不能同时成立；数量累加也要确认动作语义是增加量还是最终量。字段看起来都是数字，业务含义不同，合并方式就不同。

冲突提示要给出可行动信息。不要只写“同步失败”。应告诉处理人是哪张单、哪件货、设备记录了什么、服务器当前是什么、为何不接受、可选处理是什么。现场员工未必有权改库存，可以把记录转给班组长或后台审核，但原始操作不能丢。

## 待同步队列要能被人看见

![仓库PDA恢复网络后分批补传并处理冲突的示意图](https://www.rfidpda.cn/uploads/allimg/20260716/1-260G6134K2451.jpg)

网络恢复只是开始，补传还要面对重复、过期和业务冲突。

很多离线方案技术上有队列，现场却看不到。员工交班时不知道设备里还有几十笔待传，随手关机或放回充电柜；下一班换了一台设备，数据仍留在原机器。等盘点差异出现，大家才开始找是哪台PDA没有上传。

队列至少要在三个位置可见。当前任务页显示本任务待传数量；设备首页显示全机待传总数和最早产生时间；管理端能按设备、人员、任务和错误类型查询。这样员工、班组长和IT都有自己的观察窗口。

交接规则也要跟着改。设备归还前检查待传数量，网络正常时等待同步完成；确实无法补传，则把设备编号、待传数量和任务交给下一班或管理员。不能只交机器，不交状态。

本地数据清理必须谨慎。只有服务端明确确认处理完成，设备端才能把记录从待传队列移出。即使从工作队列移出，也可以按审计需要保留一段只读摘要。不能因为用户点了“清空缓存”就把未同步业务一并删除。

存储空间也要监控。离线记录不仅有文本，还可能包含照片、签名或附件。设备长时间断网，空间会逐渐被占满。系统应设置容量预警和业务上限，先阻止继续拍大附件或提示联网处理，不能等数据库写满才发现后续每一笔都保存失败。

## 多台PDA离线，比单机离线难得多

单台设备断网，很多冲突还不明显。一个仓库同时有几十台PDA，大家在同一区域离线工作，恢复后会形成集中补传和业务争用。

任务分配要尽量减少重叠。离线前可以把区域、货位、波次或单据明确分给设备和人员，避免两台机器都拿到同一份可执行任务。若业务允许共享任务，也要在服务器端定义重复和冲突处理，而不是指望员工口头协调。

恢复网络时，不必让所有设备瞬间冲上来。后台任务可以加入轻微随机延迟或按批次发送，服务端也要有速率控制和队列处理能力。否则无线网络刚恢复就被大量附件和记录塞满，员工又会看到连接时好时坏。

多设备环境还需要统一应用版本和数据结构。旧版本设备离线很久，期间服务端接口和字段发生变化，补传时可能无法解析。接口应有兼容策略，本地记录应带应用版本和数据版本，升级流程要考虑待传队列。设备有未同步数据时，强制升级、清除应用数据或恢复出厂都会带来风险。

设备身份也要稳定。不能只靠员工账号判断来源，因为员工可能换机，设备也可能共用。每条记录应能追到人员、设备、应用版本和任务。这样出现同一账号在两台设备产生冲突时，才知道从哪里查。

## 一次靠谱的断网演练，应该故意制造麻烦

离线演练之前，还要确认设备手里的基础数据有多新。物料、货位、条码规则、批次状态和任务权限会变化，设备若几天没有联网，虽然页面还能打开，做出的判断却可能基于旧数据。系统应为可离线使用的数据设置版本和有效窗口，下载时记录更新时间，超过边界后限制高风险操作，并提示先完成同步。

基础数据更新也不能与待传操作互相踩踏。设备恢复联网后，如果先把本地字典全部替换，再解析旧记录，可能出现代码含义变化；如果只顾上传，不拉取已经关闭的任务，又会继续产生冲突。更稳妥的顺序要按业务确定，并保留旧记录产生时使用的关键标识和版本。员工不需要知道版本号细节，但页面要告诉他当前任务是否仍可离线执行。

设备长时间离线时，权限也可能过期。人员调岗、账号停用或单据授权撤销后，本地会话不能无限延续。低风险采集可以先保存为待审核记录，高风险动作则应在权限无法在线确认时暂停。这样做会让少数任务等待，却避免恢复联网后发现整批数据都由无效权限产生。

在线演示跑通后，应安排一轮断网演练。不是只关一下Wi-Fi看页面提示，而是把可能导致数据重复和丢失的时刻都走一遍。

可以在扫码前断网，确认任务是否还能打开；扫码后、本地保存前让应用退出，确认不会显示假成功；本地保存后、上传前重启设备，确认队列还在；请求发出后立刻断网，模拟服务器可能已处理但设备没收到确认；恢复网络时连续点击同步，确认服务端不会重复入账。

还要试服务端主动拒绝。让单据在设备离线期间被关闭、库存被他人占用、条码状态改变、用户权限撤回，再看补传结果。网络失败会重试，业务失败应进入待处理，二者不能混在一起无限重试。

应用升级和电量耗尽也值得测试。设备里有待传记录时安装新版本，记录能否迁移；电池突然耗尽后再开机，末笔记录是否存在；本地数据库损坏或空间不足时，应用能否阻止员工继续产生“看似成功”的操作。

演练结束后要对账。设备产生了多少本地操作，服务端成功多少、重复识别多少、冲突多少、失败多少，数量应能闭合。只看页面没有报错不够，必须把每个本地操作编号和服务端结果对应起来。

## 离线能力上线后，运维看什么

系统上线后，待传数量是很有用的健康指标。正常情况下，网络恢复后队列会逐渐下降。如果某台设备长期有旧记录，可能是网络覆盖、后台任务、账号权限、应用版本或数据库状态有问题。

还可以关注最老待传时间、平均补传耗时、重复请求数量、业务冲突数量和不同错误类型分布。重复请求并非全是坏事，它说明重试机制在工作；服务端能识别并安全返回，才是关键。若重复突然增多，可能意味着网络响应丢失或客户端频繁超时。

日志要能关联同一个操作编号，但不要把敏感业务内容无边界地写进日志。记录必要的状态、错误码、设备和版本即可。条码、人员和业务数据按权限查看，日志保留周期也应符合企业安全要求。

告警要避免噪声。偶发一笔重试不必半夜叫醒IT，待传积压超过业务允许时间、同一错误持续出现、多个设备同时失败、存储空间接近上限时更值得提醒。告警最终要落到处理人和动作，否则只是多一个红点。

## 仓库流程也要为断网留后路

技术设计再细，现场没有规则仍会乱。仓库需要明确断网由谁确认、哪些岗位继续、哪些动作暂停、离线任务如何分配、设备如何交接、网络恢复后谁看同步结果、冲突由谁审核。

员工培训应使用真实异常。让大家看到“已离线保存”和“已同步”的区别，知道不能因为没看到服务器结果就反复扫，知道换设备前要检查待传数量，也知道业务拒绝不能靠多点几次解决。

纸面应急单据是否保留，要看业务。如果保留，就要规定纸单和PDA数据如何避免重复录入；如果不保留，就要确保离线数据有可靠存储和设备备用。两套方式同时存在却没有统一操作编号，恢复后很容易同一动作录两遍。

断网期间还要控制任务范围。网络大面积故障时，班组长可以冻结新的高风险出库，只让员工完成已分配的低风险采集。这样虽然牺牲一部分速度，却减少恢复后的冲突堆积。离线设计的目标是有序降级，不是让系统假装网络从未断过。

## 验收离线功能，关键看账能不能闭合

仓库PDA断网后能不能继续作业，答案取决于业务类型和系统设计。能扫出条码，不等于记录已保存；记录留在本机，不等于服务器已入账；服务器收到请求，也不代表不会重复执行。

一套可用的离线方案，会把每次操作做成有身份、有状态、可恢复的本地记录。设备在本地写入成功后再提示暂存，后台在网络满足条件时按规则补传，所有重试沿用同一个操作编号，服务端负责幂等去重和业务校验，冲突进入清楚的处理流程。员工则能随时看到还有多少数据未同步。

验收时不要只演示“关网还能扫”。要把闪退、重启、超时、重复点击、单据变更、多机并发和长期积压都跑一遍，再把设备操作数与服务端入账数逐笔对上。只要每一笔都能说明现在在哪里、经历了什么、处理结果如何，断网就只是一次可管理的降级，而不是一场事后猜账。

# 仓库断网后PDA还能不能继续作业？离线缓存、补传和防重复怎么设计

仓库网络断了，员工手里的PDA还亮着，条码也能扫出来。问题是，这一枪到底算不算完成？

如果页面立刻报错，员工只能停工等网络；如果页面显示成功，却没有把数据保存下来，网络恢复后账上少一笔；如果设备把数据暂存在本地，员工又点了几次提交，恢复联网后可能冒出多笔重复记录。现场最怕的不是屏幕上出现“无网络”，而是员工以为做完了，系统却留下了一本说不清的账。

断网继续作业并不是给PDA加一个“离线模式”开关。它需要设备端、服务端和仓库流程共同约定：断网时哪些任务允许做，数据先存在哪里，怎样标记每次操作，恢复后按什么顺序补传，服务端怎样识别重复，发生冲突时谁来处理。少了其中一环，离线功能就可能从保生产变成制造差异。

## 先把三个问题说清楚：扫到了、保存了、入账了

仓库员工听到扫码成功提示，通常会理解成动作已经完成。但从系统角度看，一次扫码至少经过三个阶段。

先是设备读到了条码。这个阶段只证明扫描模块识别出一串字符。条码可能还没通过业务校验，也没有写入本地记录。

随后是PDA把这次操作保存下来。联网时，应用可能直接请求服务器；离线时，应用应该把必要数据可靠地写入本地存储。只有写入成功，才有资格告诉员工“已暂存”。如果只是把数据放在页面变量或内存里，应用闪退、系统回收进程或设备重启后，记录就可能消失。

末端是服务端确认入账。服务端需要完成单据、库存、批次、货位、权限和状态检查，写入业务数据库，并返回清楚结果。这个阶段完成后，PDA才可以把本地记录标记为已同步。

这三个阶段的提示不能混成一个绿色对勾。更合适的做法是让员工看懂当前状态：条码已识别、操作已保存到本机、服务器已确认。现场不需要理解数据库术语，但要知道这一笔现在能不能交接、能不能清除、是否还在等待补传。

[!\[无联网无通信模块的PDA手持终端实拍图\](https://www.rfidpda.cn/uploads/allimg/20251211/1-251211145FQ58.jpg)](https://www.rfidpda.cn/pro/other/zf/2402.html)

## 不是所有仓库动作都适合离线

“断网也能干”听起来很方便，可仓库动作的风险并不相同。

盘点采集通常比较适合离线。员工记录某货位看到了哪些货、多少数量，数据可以先保存在本机，联网后再汇总。即便服务器上的库存期间有变化，系统也可以把盘点结果当作一个待复核事实，而不是直接修改可用库存。

库内巡检、设备点检、拍照留痕、货位信息采集，也常能采用类似方式。它们的核心是先记录现场发生了什么，后续再同步。

但出库确认、库存扣减、序列号排他占用、波次分配、跨库调拨生效等动作更敏感。两个员工都在离线状态下看到同一份旧任务，各自完成操作，恢复网络后才发现争用了同一库存。设备端无法凭本地旧数据判断另一个人刚做了什么。

因此，离线范围要按业务风险划分。可以允许离线采集，但把最终生效留到服务器；可以允许完成当前已下载任务，却不允许离线领取新任务；可以允许记录数量，却把超额、冻结、批次失效等校验放到补传时处理。目标不是让所有按钮在断网时仍可点击，而是让低冲突动作继续，让高冲突动作停在可控边界。

如果一个动作涉及金额、排他序列号、库存承诺、质量放行或法规记录，就更应谨慎。离线能力不能削弱原有审批、权限和追溯要求。必要时宁可提示等待联网，也不要为了“不断工”绕开关键控制。


封面：/uploads/allimg/20260716/1-260G613563U02.webp