应用场景示例：现场巡检APP的离线记录与同步设计
场景从哪里来
巡检类APP的需求，往往不能简单理解为“把纸质表搬到手机上”。真正麻烦的是现场条件：配电间、地下室、车间角落、山区基站，网络时有时无；巡检员一手拿设备一手点屏幕，填到一半被打断是常态；回到办公室才发现有几张照片没传上去。如果按纯在线表单的思路做，页面一断网就转圈，填过的内容还可能丢，使用的人很快会退回纸笔。
下面这个示例围绕“离线记录与联网同步”展开，讨论需求边界、方案取舍，以及验收时该关注哪些点。它是对一类常见场景的拆解，不代表某个已完成的交付项目。
先把“离线”的边界说清楚
“支持离线”这句话太粗，落到开发上至少要回答四个问题。
- 离线时能做什么：只读缓存的任务列表，还是可以新建记录、拍照、签字？
- 数据存在哪里、能存多久：换手机、清缓存、卸载重装之后，未同步的记录还在不在？
- 联网后谁先谁后：一批记录同时上传，顺序由什么决定？
- 同一条记录被两个人改过，以谁为准？
这几个问题不定下来，后面写代码会反复返工。比较稳妥的做法是把每条巡检记录当成一个小状态机：草稿、待同步、同步中、已同步、同步失败、冲突待处理。界面上用状态文字和颜色区分，使用的人就不必自己猜“到底传上去了没有”。
取舍：不做全量同步，做增量与队列
一种省事的思路是把服务端数据整体拉到本地，离线时随便查。省事，但代价大：任务表、设备档案、历史记录加起来可能几百兆，手机存储和内存都吃紧，首次打开要等很久，权限或数据范围变化也难及时反映。
更常见的做法是按人、按天、按任务范围拉取：登录后只同步当前巡检员未来几天要做的任务和必要的设备基础信息，历史记录留在服务端按需查询。这样首次同步的数据量可控，离线时也不至于查不到手头的活。
另一处取舍是照片。原图几兆一张，一次巡检十几张，全存本地很快会占满空间。可以现场拍完后先压缩到适合查看的尺寸存本地，原图在联网时单独排队上传；也可以只保留压缩图。具体选哪种，要把“是否需要原图存档”写进需求确认单，由业务方决定，不能由开发顺手拍板。
方案由哪几块组成
本地存储与数据模型
离线记录要落到本地数据库，字段、主键、时间戳要在开发前定下来。记录主键建议在客户端生成，比如用时间戳加随机串，而不是等服务器返回ID，否则离线新建的记录在关联照片、关联签字时会很别扭。
同步队列与幂等
每条待同步记录进入队列，按创建时间排队；上传接口带唯一请求号，服务端做幂等处理，同一条记录重复提交只落一份。这一条看起来多余，实际很重要：弱网下客户端超时重试非常频繁，没有幂等就会出现重复记录，事后清理的代价远高于当初多做一步。
附件单独通道
文字记录和照片分开上传。文字数据小，先传；照片逐张或分片上传，失败只重传单张，不拖累整条记录。上传进度要在列表里可见，否则使用者不知道还要等多久，容易反复点击。
冲突与异常状态
服务端为每条记录保留版本号，同步时比对。版本不一致时不要静默覆盖，把记录标为“冲突待处理”，本地与服务端各留一份内容，交由后台或指定人员合并。这个页面不讨喜，但少了它，数据出了问题就无从追溯。
实施步骤怎么排
- 梳理巡检表单与流程：检查项、必填规则、拍照要求、签字环节，以及哪些字段允许离线修改。
- 确认离线范围与保留策略：拉取多少天的任务、本地保留多久、换设备后未同步数据如何处理。
- 设计同步协议：请求号、版本号、时间来源、重试间隔与上限，写成一页文档双方确认。
- 开发与联调：先跑通“断网新建—联网上传”这条最短路径，再补冲突、附件、批量等分支。
- 小范围试用：用几台不同系统的手机，在真实弱网环境里跑一遍，记录失败原因。
- 上线前核对后台：同步日志、失败记录、冲突处理入口是否可用。
验收时盯住这些动作
按功能清单走一遍容易，真正暴露问题的是几组具体动作：开启飞行模式填写三条记录后再恢复网络，看是否全部上传且不重复；上传过程中强制终止APP，重新打开后队列是否还在；两台设备修改同一条记录，看冲突提示是否出现；把手机时间调乱，看记录时间以哪个为准；上传十几张照片时切到后台再回来，看进度是否续上；卸载重装后，本地未同步数据是否有明确提示，而不是静默丢失。
后台一侧同样要验收：能否按人、按时间筛出同步失败的记录，能否看到失败原因，能否手动触发重传。这些能力决定了上线后出问题是“十分钟能查清”，还是“只能让巡检员重填一遍”。
哪些事要提前讲明白
离线能力有边界，交付前把边界写进说明，比事后解释省事。比如：离线状态下拿不到最新派单；清除应用数据会丢失本地未同步内容；照片上传依赖网络，量大时需要等待；冲突记录需要人工处理，不会自动合并。这些写进使用说明和验收单，使用方的预期才不会跑偏。
如果这套APP还要对接已有的巡检管理系统，接口、账号体系、数据归属需要在开发前单独理清。那部分工作量与客户端离线逻辑是两件事，排期时分开评估更稳妥。