同步延迟会导致设备间状态不一致
别名: 同步延迟 · 最终一致 · Chrome 标签同步 · eventual consistency
概念解释
电脑上刚关掉的标签，拿起手机打开 Chrome 还在；手机上改过的一篇文档，回到电脑仍是上一版。两端都「有这份东西」，但内容停留在不同时刻。同步延迟造成的不一致不是接续没把活动交出去，而是多台设备各自持有副本、副本还没有赶上。人把「我刚在那边改过」当成全局事实，延迟把这个事实拆成两套世界。这条只谈时间差带来的新旧并存，不谈两台都改了之后谁赢，也不谈已读标记该不该比正文先到。
机制
跨设备同步几乎都是最终一致（eventual consistency）：先在本机写入，再找一个机会传到服务器和其他设备。机会取决于网络、节电策略、应用是否在前台。手机在后台被系统冻结时，电脑上的修改会在手机里躺成旧副本；反向亦然。人没有「副本」这个概念，只有「我的东西」——刚在 A 上做完的操作，在 B 上应当已经发生。延迟一旦长过任务切换的那几秒，B 上的旧状态会被当成真相：重新打开已关的标签、把改过的句子改回去、把已听过的一集从头放。更糟的是没有「正在追上」的信号时，旧状态看起来完全正常，人不会等，而会基于过期世界继续操作，把延迟变成一次新的分叉。
怎么研究
多设备生态里的日记和日志能抓住「我以为那边已经是新的」这种时刻。实验室可以做成双机对照：同一账号两台设备，在 A 上做出可见改动，立即在 B 上读取，记录 B 追上的时间和其间人采取的错误动作。
自变量：同步触发条件（即时、应用回到前台、周期性）、网络与省电约束、是否显示「还在同步」。 因变量：两端一致的等待时间、基于过期状态发生的误操作次数、把不一致归因于「自己没存上」还是「系统还在传」的比例。
不要用服务器上的提交成功当作用户侧一致：人判断的是另一块屏幕。实验室网络往往好于通勤地铁，测到的延迟会偏短。日记要分开「内容还没到」和「到了但入口找不到」——后者不是同步延迟。
边界
只在一台设备上完成、从不立刻换机的任务感觉不到延迟。本地权威数据（正在录的音频、尚未上传的相机卷）本来就允许源设备领先，把「尚未传到其他设备」标出来即可，不必假装已经全局一致。冲突已经发生之后，问题变成规则而不是快慢。弱网和飞行模式是延迟的极限形式：此时应显式进入离线，而不是继续展示一份看起来在线、实际冻住的界面。
怎么落地
- 在人最常换机的表面给出同步未完成的迹象：标签列表标「还在更新」、文档旁显示「电脑上的修改尚未到达」，避免旧列表以完成态呈现。
- 回到前台时主动拉一次，不要只等下一次周期性同步；换机路径上的延迟预算按秒计，不按分钟计。
- 对会引发误操作的对象（打开的标签、正在编辑的稿、播放位置）优先推，大附件可以更慢。
- 验证：电脑 Chrome 关掉若干标签并改一份云文档，立刻打开同一账号的手机。在同步完成前，手机不得把已关标签和旧文稿显示为确定的当前状态；若仍显示旧值，必须能看出「尚未追上」。