K8.02.3read state and progress sync设计
已读、进度等状态的同步预期高于内容
别名: 已读同步 · 播放进度 · Kindle 进度 · 跨设备已读
概念解释
邮件在手机上划掉未读，打开电脑邮箱它又亮着；电子书在平板看到第 120 页，晚上换手机从第 80 页开始。正文可以稍晚到达，已读、播放位置、阅读进度这类元状态一旦落后，人会立刻觉得「这台设备不认我刚做过的事」。对进度的容忍低于对章节、附件、封面图的容忍。Kindle 和播客把进度当成主同步对象，不是因为内容不重要，而是因为进度错了，人会重复劳动或漏过更新。
机制
内容同步失败，人看到的是「还没有」：缺一章、缺一张图，等待是可理解的。元状态同步失败，人看到的是「系统否认刚才的动作」：明明听过、读过、处理过，另一台设备把它当作未发生。这会直接打击操作闭环——划掉未读、把一集标为播完、把进度条拖到某处，这些动作的意义就是改变以后每一台设备上的待办。元状态体积小、变更频繁，按理说应该比大附件先到；若同步队列按文件大小或按「打开时再拉内容」来安排，进度反而被排到后面。人切换设备往往就是为了接着读、接着听，进度是换机的理由本身，晚到等于白换。
边界
单设备使用、从不在另一台上看同一收件箱或同一本书，进度不同步不会被察觉。多人共享的进度（家庭成员接着看同一部剧、公共账号的邮箱）不应默认同步到每一个人的「已读」——那是身份问题，不是延迟问题。有意的「这台设备保持独立进度」（小孩的学习机、一台专门用来重看的平板）需要独立配置，不能被全局进度强行覆盖。离线听完一整集再恢复网络，进度应在内容补传之前先写回，否则在线的那台会按旧位置再推一次通知。
怎么落地
- 把已读、未读、播放位置、阅读页码从内容附件的队列里拆出来，换机路径上优先推送这些字段。
- 在另一台设备仍显示旧进度时，不要用「你有新邮件 / 继续播放」去打断一个刚刚在源设备处理完的对象。
- 允许用户看见「进度来自哪台设备、何时」；当两台进度不同且无法判断先后时，提示选择，而不是默默跳回旧页。
- 验证：手机把一封邮件标为已读、把一本电子书翻过一章、把一集播客拖到中段，立刻打开电脑客户端。在正文或音频可能仍在缓冲时，已读灯、章节位置和播放头必须已经对齐；若内容还没到，进度也不能回退。