K8.02.2sync conflict resolution设计
冲突需要明确的解决规则
别名: 同步冲突 · 冲突副本 · last-write-wins · 合并冲突
概念解释
同一段笔记在飞机上的手机里改过一句，在办公室电脑上又改过另一句，落地后两台都声称自己是最新。延迟造成的是新旧并存；冲突是两端都写出了无法自动合成的新版本。iCloud 备忘录把它变成「冲突的副本」，有的日历则静默留下后写入的那次。没有公开的规则时，人不知道丢掉的是哪一次修改，也不知道下次该先等哪一台。规则要事先可预期，不能等丢了数据再解释。
机制
一旦两台设备在未对齐的窗口里都提交了写入，系统必须在三种策略里选一种：后写覆盖（last-write-wins）、并排保留（冲突副本 / 分叉）、或按字段合并。后写覆盖实现便宜，代价是先写的那次从界面上蒸发，人会以为自己没存上。并排保留不丢字，但把「哪一份才是我的笔记」变成新任务，副本标题若只是「的拷贝」仍等于没规则。按字段合并在通讯录、日历这种结构化对象上可行，在自由文本段落上会拼出谁都不曾写过的句子。人要的不是策略名字，而是一条能用来决策的预期：再离线编辑之前，先让某一台追上；或者接受系统会生出第二份，并知道去哪找。规则若只写在工程师的故障手册里，界面上的每次消失都像随机故障。
边界
只读副本、或一端被明确标成「浏览、不能改」时，不会写出第二份新版本，冲突规则用不上。协同编辑的操作变换（多人同时打字的文档）有自己的合并语义，不应退化成整篇后写覆盖——那是另一类产品。二进制物件（一张已导出的图、一段已编码的视频）往往只能选保留两份或选一边，没法按字段拼。家庭共享的提醒事项上，冲突可能来自两个人而不是两台设备，规则还要能说清是「谁的修改」而不只是「哪台机器」。
怎么落地
- 在会离线编辑的对象上先选定并公开一种策略：后写覆盖、冲突副本、或按字段合并，写进产品能被用户看见的说明，而不是只留在同步日志。
- 后写覆盖必须留下可找回的前一版（版本历史里的一条），不能让被覆盖的句子从此不可见。
- 生成冲突副本时，用「手机上 14:02 的修改」这种可辨来源的标题，并在打开时提示还有另一份，而不是让人自己在列表里撞见「的拷贝」。
- 验证：同一篇笔记在飞行模式的手机上改第一句，在离线电脑上改最后一句，恢复网络。确认实际留下的是事先声明的那种结果——一份带历史、两份并排、或按句合并——并且人能指出丢掉或分出去的那部分在哪。不要用「以服务器为准」这种内部话术面对用户。