各端的临时状态不一致是同步协作的常态而非故障
别名: 临时不一致 · 最终一致性体验 · 分叉与收敛
概念解释
多人同步协作时，各端屏幕上的内容随时可能不一致：一个人的修改还没传到其他人端上、两个人的修改正在各自本地生效、同一段文字在两块屏幕上短暂地长着不同的样子。这不是 bug，而是分布式系统的物理现实——光速与网络设备决定了状态传播需要时间，强一致的「所有人同一瞬间看到同一画面」在广域网上既不可达也不必要。正确的心理模型是最终一致：各端允许临时分叉，但每次分叉都会收敛；工程与体验设计的目标不是消灭分叉，而是把分叉的窗口、可见性与收敛过程管理好。
机制
强一致要求所有副本在每次变更上同步达成共识，代价是每次操作都要等最慢的参与者投票——延迟随人数与地理距离上抬，操作回到「全网确认才显示」，同步协作的手感被摧毁。协作系统普遍放弃强一致，转而让各副本先接受本地操作、异步收敛：你打的字先上你的屏，同时向其他人传播；传播间隙里，两端短暂不一致。这个窗口通常在几百毫秒到几秒之间，用户几乎无感；真正的问题出现在窗口变大时（弱网、大文档、跨洲），不一致从「无感的背景噪声」变成「看得见的分叉」——对方基于旧状态做了决定、引用了已删除的段落。因此设计问题从来不是「如何消除不一致」，而是三个具体的：分叉窗口能压到多小（性能）、分叉期间他人基于旧状态行动的风险如何提示（感知）、收敛时如何让结果可理解（合并与变更呈现）。把不一致当故障对待的团队会去加全局锁，结果是用并行度换一致性，得不偿失。
怎么研究
- 范式：分布式系统的形式化分析给出收敛保证（在何种操作语义下各端必然收敛到同一状态）；体验层面用受控实验操纵「他人视图滞后」的时长与可见性，观察基于旧状态行动的错误率；真实部署的日志可以统计不一致窗口的分布（p50/p95）及其与用户行为（重复询问「你看到了吗」）的相关。
- 变量：自变量为收敛延迟、滞后提示的有无；因变量为基于旧状态的错误动作数、对齐沟通量、对系统可靠性的主观评分。
- 在界面研究里的用途：为「不一致需要被感知到什么程度」定阈值——哪些场景必须提示滞后，哪些场景提示反而添乱。
- 方法论注意点：不一致的体验效应高度依赖任务对同时性的敏感度——聊天可以容忍秒级分叉，协同操作一台设备不能；跨任务的结论不可直接搬用，必须以任务的同时性需求为边界条件报告。
边界
「常态」的定语是临时的、会收敛的。不收敛的分叉（脑裂后各自演化、合并不了）是真故障，落入冲突处理的范畴；无界的分叉窗口（弱网下十分钟不一致且无提示）也不是常态，是体验缺陷。强一致仍有一席之地：计费、名额分配、库存这类「先后到达决定成败」的操作，最终一致会造成超卖与重复扣款——协作内容用最终一致，关键竞争性操作用集中仲裁，两套策略在同一产品里并存是常态而非妥协。
怎么落地
- 把工程目标从「消灭不一致」改为「管理分叉」：压窗口（增量同步、操作压缩）、给感知（滞后时的对方状态标记）、管收敛（合并结果可见）。
- 在收敛延迟超过任务敏感阈值时给显式提示：对方可能未看到最新内容的标记、消息的「已送达/已读」分层。
- 竞争性关键操作（抢占、扣减）单独走集中仲裁，不与内容同步共用最终一致通道。
- 验证：采集各端渲染时间戳差，统计不一致窗口的分位数分布；将窗口分布与「你看到了吗」类沟通频次对齐，确认阈值设置与任务敏感度匹配。