I3.10.3understandable eventual consistency设计
本地与云端的最终一致性需要用户能理解的收敛过程而非黑箱
别名: 最终一致 · 收敛过程 · sync convergence · 不是黑箱
概念解释
本地优先承认：此刻这台设备上的真，和云端或其他设备上的真，可以暂时不一样。它们最终会一致（eventual consistency）。人要能理解「最终」是怎么来的：哪些还没送出、哪些正在合、哪些已经对齐。若同步只是一个转圈然后突然换文案，收敛是黑箱——模型无法预测下一眼会看见谁的字。
理解不是要人会 CRDT。理解是能回答三句：我的改动走了没有、别人的改动到了没有、现在看到的是不是已经对齐的那一份。
机制
最终一致把「同一份」从瞬时承诺改成时间上的过程。过程有方向：未发送 → 发送中 → 已对齐，或未拉取 → 正在合并 → 已对齐。每一步都是可命名状态。黑箱把这些步压成「同步中」，结束时像素替换。人不知道替换是「我的还在、别人的加进来了」，还是「我的被盖了」。下一次离线决策会按错误的假设做。
可理解的收敛把过程外化成少量稳定信号：待发送的条数、上次对齐的时刻、正在合并的对象名。信号必须单调：待发送只减不无故跳回，对齐时刻只往前走。非单调会被读成系统在撒谎。合并若会改动已看见的句子，收敛过程要在改动发生时给一个可理解的挂钩（「来自电脑上的一版」），而不是事后让人自己做 diff。
边界
单设备、从不同步到任何云的工具没有收敛过程可讲。强一致的中心权威产品也不该假装最终一致——那里的故事是「先请示再显示」。收敛可以在后台进行，只要人查询时能得到那三句的答案；不必把每一步都做成动画。极高频的字符级协同（共同光标）用「已对齐」作为默认假设，只在延迟或冲突时打开过程视图，否则过程本身变成噪声。加密同步若不能在界面上展示变更来源，至少要能展示「已对齐 / 未对齐」，不要为了加密把两态都藏起来。
怎么落地
- 给同步三个可查询的值：待发送数量、待拉取或合并的对象、最近一次对齐时刻。
- 「已对齐」只在本地与已连接副本没有未交换变更时点亮；点亮前不要用完成色。
- 合并导致可见文本变化时，指出方向（「加入了来自另一台设备的修改」），不要无声换句。
- 验证：两台设备先后离线各改一段。恢复一台，看收敛信号是否从「有待发送」走到「已对齐」，且另一段出现时人能说出它从哪来。把同步做成只有一个转圈、结束后句子已变但无任何阶段名，判为黑箱。再问一个没看过实现的人「现在两边一样了吗」——答不上来就是不可理解。