静默覆盖是最严重的协作错误
别名: 丢失更新 · last write wins · lost update
概念解释
静默覆盖（lost update / last-write-wins without notice）是后一次写入在对方不知情时取代先一次写入，界面上既没有冲突，也没有「你的稿被换掉了」。被覆盖的人仍看着自己的字，直到刷新、重开、或别人问起。它比可见的冲突更糟：冲突至少把两边留在场上；静默覆盖让一边从产品里消失，历史里也不一定留得下可找的痕迹。在场显示和冲突选择都是为了不要走到这一步。不能把「后来的保存成功了」当成协作成功。
机制
许多存储模型按整份文档或整行替换，时间戳较新的那份获胜。本地编辑在弱网或长会话里时间戳更晚，于是赢的是「谁最后点了保存」，不是「谁的改动该留下」。失败之所以静默，是因为保存控件给出了成功反馈——对后写入的人是真的成功，对先写入的人是无事件。人的检测依赖偶然：打开发现句子没了、或对方说没看见自己的话。没有事件就没有时机去恢复，连撤销栈都指向自己最近的击键，而不是被覆盖的那一版。规模上，单元格、评论、整章都可能被整块替换，越粗的写入单元，一次静默覆盖吞掉的他人工作越多。
怎么研究
两人离线或延迟同步后保存同一记录。比较：后写覆盖且双方都看到成功、后写覆盖但先写者收到「你的版本已不是当前」、阻止后写直到看见差。
自变量：写入单元（整份 / 字段）、失败是否通知先写者、被覆盖内容是否自动进历史。 因变量：先写者发现丢失的延迟、丢失范围（字 / 段 / 整份）、是否还能找回。
实验室如果让两人轮流保存并盯着对方屏幕，静默性会被破坏。要隔离，并用「保存成功」的反馈当作先写者仍以为自己的稿活着的证据。发现若只发生在访谈里，说明产品从未给出事件。不要用版本历史的可比较性为静默覆盖开脱——历史里有不等于当时知道丢了。
边界
真正的字段级自动合并（两人改了不同字段）不是覆盖，不应报警。明确的「覆盖别人的草稿」若带预览和确认，是可见的危险操作，不是静默。备份导入、管理员强制回滚会整份替换，必须当成高后果事件通知所有打开者，否则就是静默覆盖换了一件衣服。只读副本被别人更新时，应提示「内容已更新」，这是刷新，只要不把本地未保存的编辑丢掉。
怎么落地
- 禁止在未提示的情况下用整份较新时间戳覆盖另一人的未合并写入；至少把先写者的内容留在历史，并给先写者一条「你的改动未进入当前稿」。
- 保存成功只发给其写入确实进入当前稿的人；对将要覆盖他人的保存，先展开差再让人选。
- 写入尽量落到字段或段落，而不是每次保存替换整份对象。
- 验证：两人隔离各改一处重叠的句子后保存。任何一方看见「已保存」而另一方的句子消失且当时没有事件，即为静默覆盖。再检查被覆盖的句子能否在不靠运气翻历史的情况下回到当事人面前。