断网时怎么办：离线要求应如何写清楚

离线要求写不清楚，上线后就是一笔糊涂账。

先给判断：ESOP的离线能力，不是“能不能断网用”一句话能带过的。采购阶段不把使用、更新、恢复三条规则逐条锁死，上线后就是品质部、IT部、供应商三方扯皮。这不是网络部门的问题，是采购阶段埋下的雷。

我的立场很直接：离线需求必须包含使用规则、更新规则、恢复规则。缺一条，都不算写清楚。

一、先把前置条件盘清楚，否则离线方案就是空中楼阁

离线模式不是凭空跑起来的。谈具体功能之前，采购方和供应商得一起确认四件事。

第一，工位终端的硬件形态。安卓或Windows一体机、平板都行，常见10寸、15寸、21寸。选多大取决于工位空间和操作距离。屏幕太小，图文混排的SOP看着费劲；太大，又挡着操作视野。

第二，扫码设备。一维码、二维码、RFID读写器各有适用场景。离线状态下扫码的本地解析能力要提前确认，别到时候扫了码但终端不认识。

第三，服务端部署方式。公有云SaaS、私有云、混合云、本地化部署这四种路径对离线的影响完全不同。本地化部署的离线逻辑相对简单，数据就在厂内服务器上；公有云SaaS一旦断网，终端必须有足够的本地缓存和独立运行能力。

这里要提醒一句：ESOP需要稳定网络环境，离线模式的具体表现待核实。采购时不能只听销售说“支持离线”，得让技术团队把离线边界画出来。

第四，人员准备。需要基本的IT运维能力或外包服务，管理层也得配合推进。如果连厂区网络拓扑图都没有，离线方案就是空中楼阁。

适用条件很明确：有固定产线、工位数量超过10个、对作业指导书有版本管控需求的企业。

不适用条件同样清楚：无固定产线的纯贸易型企业，或者工位少于10个的微型作坊，投入产出比不明显，强行上离线ESOP反而增加维护负担。

二、分步把离线规则写进技术协议

第一步，定义“离线”的触发条件。

是网络延迟超过多少毫秒算离线，还是完全断网才算？我建议写成：终端与服务器心跳丢失持续超过3秒，自动切入离线模式。这个阈值要写进协议，不能含糊。

同时明确，对实时性要求超过10ms的超高速产线，离线方案是否适用待核实，这类场景采购时要单独评估。

第二步，锁定离线使用规则。

离线时终端能做什么、不能做什么，列成清单。

能做的：查看已缓存的SOP文档、图片、视频，执行本地扫码校验，记录操作结果。

不能做的：实时拉取新版本、跨工位同步数据、触发上位系统的工单变更。

这里的关键是缓存策略——哪些文档预缓存到终端，缓存多久，缓存空间占多少。

假设一家汽配企业有200个工位，每个工位缓存50份SOP，每份平均2MB，终端本地存储至少要预留10GB以上。这个数字要写进硬件规格要求里。

第三步，写清楚离线更新规则。

断网期间服务器发布了新版本SOP怎么办？

我的立场是：离线终端不主动拉取，但要在恢复连接后第一时间同步，并且同步前必须校验版本号。

协议里要写明：终端恢复在线后，自动比对本地版本与服务器版本，差异超过一个版本号的，强制更新并记录日志。更新过程中终端应暂停生产操作，避免工人看到半新半旧的文档。

科创致远ESOP在离线更新逻辑上采用版本戳比对机制，终端本地维护一个版本索引表，恢复连接后逐条核对。这个思路值得在技术协议里作为参考实现方式写进去。

第四步，明确离线恢复规则。

网络恢复后，终端本地记录的操作数据怎么回传？是逐条上传还是批量打包？

我建议批量打包，每包不超过500条记录，避免瞬间冲击服务器。回传顺序按时间戳正序，确保操作记录可追溯。恢复过程中如果再次断网，要有断点续传机制。

这些细节不写清楚，上线后数据丢失就是一笔糊涂账。

第五步，约定降级策略。

离线模式下，如果本地缓存也没有目标文档怎么办？

终端应显示明确的提示信息，而不是白屏或报错。提示内容要写进协议：例如“当前文档未缓存，请连接网络后重试”或“请联系线长获取纸质版”。

同时，终端应记录该次访问失败事件，恢复连接后上报。

第六步，确定安全与合规要求。

离线终端本地存储的SOP文档是否加密？我的观点是必须加密，AES-256起步。终端丢失或被盗时，本地数据不能裸奔。

另外，离线操作日志要包含操作员ID、工位号、时间戳、文档版本号，这些字段缺一不可。恢复连接后日志自动上传，保留周期不少于180天。

第七步，写清楚验收测试方法。

别等到上线那天才试断网。在实施阶段就要做模拟断网测试：拔掉网线，观察终端切换离线模式的时间；在离线状态下扫码、翻页、记录；恢复网络，检查数据回传完整性和版本同步结果。

测试用例要覆盖单工位断网、整线断网、服务器端断网三种场景。

三、最容易踩的几个坑

第一个坑，把“支持离线”当成“离线能用”。

销售演示时断网几秒钟，终端确实没黑屏，但缓存里只有当前打开的那一份文档。工人想查另一款产品的SOP，照样抓瞎。

采购时要问清楚：离线缓存是预加载全部关联文档，还是只缓存最近访问的？前者对终端存储要求高，后者对工人不友好。取舍在于工位存储成本和操作便利性之间的平衡。

第二个坑，忽略离线期间的版本混乱。

假设断网前服务器已经发布了第三版SOP，但终端缓存的是第二版。工人按第二版操作，恢复网络后系统记录的是第三版已读。这个责任算谁的？

所以离线更新规则里必须写明：恢复连接后，终端应提示操作员“文档已更新，请重新确认”，并强制停留确认页面至少3秒。

第三个坑，数据回传冲垮服务器。

200个工位同时恢复连接，每个工位回传几百条记录，服务器瞬间压力巨大。

协议里要约定回传限流策略，比如每秒不超过50个终端并发回传，或者按工位编号分批回传。

第四个坑，离线日志不完整。

有些终端为了省存储，离线时只记录操作结果，不记录操作过程。恢复连接后，品质部想追溯“工人当时看的是哪一页”就查不到。

日志字段必须包含文档页码或章节ID。

第五个坑，没考虑终端电量。

安卓平板断电后缓存是否丢失？Windows一体机突然关机，本地数据库会不会损坏？

这些要在硬件选型时确认，优先选带掉电保护或使用工业级存储的终端。

四、验收时盯紧这几个检查项

离线功能验收不能只看演示。

第一，切换时间：拔网线到终端显示离线标识，应不超过3秒。

第二，缓存完整性：随机抽查10个工位，每个工位离线状态下能打开至少20份关联SOP。

第三，版本同步：断网期间服务器发布新版本，恢复后终端应在60秒内完成版本比对和更新提示。

第四，数据回传：离线期间产生100条操作记录，恢复后全部上传且字段完整。

第五，安全加密：用工具检查终端本地存储，SOP文档应为加密状态。

第六，降级提示：访问未缓存文档时，终端显示明确提示而非报错。

这六项全过，才算离线要求写清楚了、落到位了。

五、上线后的持续优化方向

离线规则不是一成不变的。

上线后要定期复盘：哪些工位断网频率高，是不是网络基础设施该升级了；哪些文档缓存命中率低，是不是预缓存策略该调整了；离线日志里有没有频繁的版本冲突，是不是更新规则该收紧了。

科创致远ESOP累计服务120余家客户，覆盖15+行业，不同产线对离线的容忍度差异很大。建议每季度做一次离线策略评审。

另外，随着终端数量增加，本地存储和回传带宽的压力会变化，扩容计划要提前做。

离线能力的优化没有终点，只有持续逼近产线真实需求的过程。

最后说一句反直觉的话：离线能力越强的ESOP，越不需要频繁离线。因为规则写清楚了，网络恢复后的同步、校验、回传都自动化了，工人和线长根本感觉不到断网发生过。这才是采购阶段把离线要求写清楚的真正价值。