鸿蒙应用离线优先的数据同步与冲突处理实践

一、为什么选择离线优先

移动端网络质量不可控，地铁、电梯、会议室里随时可能断连。如果应用把每一次读写都直接压到服务端，用户会频繁看到加载圈和失败提示。离线优先的思路是把本地数据库当作唯一可信的读写入口，网络只是同步通道，界面永远先渲染本地数据，同步在后台异步完成。

二、本地数据模型与版本号

每条业务记录在本地都带三个字段：服务端 id、本地递增版本号 localVersion、服务端返回的 updatedAt。写入时先落库并自增 localVersion，再写入同步队列，保证"数据改了但没同步"这件事本身是可查询的。删除不做物理删除，只打 deleted 标记，避免同步过程中出现记录凭空消失。

三、同步队列与幂等设计

同步队列按插入顺序保存操作，每条操作带一个客户端生成的唯一 requestId。服务端以 requestId 做幂等去重，客户端超时重试时不会产生重复数据。队列按"先本地写、后远端写、最后回写服务端时间戳"的顺序推进，任意一步失败都保留在队列里等待下一次机会。

四、冲突检测与合并策略

同步前先比对本地记录的 updatedAt 与服务端最新版本：若服务端版本比本地基线更新，说明同一字段被别人改过，进入冲突分支。字段级合并是默认策略，不同字段各自取最新；同字段冲突则按业务规则裁决，例如数量取较大值、状态以服务端为准，并保留本地版本到冲突日志里供用户回溯。

五、弱网与失败重试

同步任务使用指数退避，初始间隔两秒，上限一分钟，并在应用切到前台、网络从断连恢复时立即触发一次补偿同步。批量接口按两百条一包切分，单包失败只回滚该包，不影响已成功的部分。

六、监控与验证

在同步链路上埋三个指标：队列积压长度、单次同步耗时、冲突率。压测时把网络切成百分之三十丢包，观察积压长度是否在恢复后两分钟内回落到零。只有当"断网可用、恢复自动补齐、重复提交不脏数据"三件事同时成立，这套方案才算真正落地。