文章 · 架构
本地优先的同步方案怎么选
同步方案的选择本质上是在回答三个问题：冲突谁来判、数据放在哪、离线的时候还能做什么。
方案一：整份覆盖
实现最简单，代价是后写入的一方会盖掉前一方。数据量小、单人使用、几乎不会并发时够用，但边界很窄。
方案二：操作日志
记录每一次改动而不是最终状态，同步时把双方的操作按顺序重放。冲突处理更细，代价是日志会一直增长，需要定期压缩。
方案三：带版本的结构化数据
给每条记录带上版本或时间戳，合并时按字段判断谁更新。实现成本最高，但多人协作场景下它是唯一稳得住的方案。
- 单人自用：整份覆盖就够了
- 需要历史与回滚：操作日志
- 多人协作、字段级冲突：结构化版本
评论6
登录后参与评论，你的发言会署上自己的名字。
林深作者@linshen·2026-08-27
先占个位：文里的数字都是本地实测的，测试环境写在文末备注里，有疑问直接在这儿回。
蔡徐@caixu·2026-08-29
本地优先的思路很好，就是冲突处理得自己写一套，工作量不小。
程野@chengye·2026-08-30
这份清单可以直接拿去做评审模板了，覆盖面挺全。
姜堰@jiangyan·2026-08-31
命名那一条看着简单，但确实是评审里最常被提出来的问题。
童语@tongyu·2026-09-01
边界情况那段写得好，很多问题都是顺利路径跑通了就当完成了。
严冬@yandong·2026-09-02
状态管理这块我更倾向于能不放全局就不放，理解成本差很多。