H3.09.2confirm before restoring recovered content设计
恢复内容需让用户确认而非静默覆盖
别名: 恢复确认 · 静默覆盖 · restore conflict
概念解释
中断之后往往存在两份世界：本地刚救回来的、服务器或另一设备上已经更新的。恢复要人确认指把两份差异摆出来，让人选择保留哪一份或合并，而不是用其中一份悄悄盖掉另一份。静默覆盖是协作和跨设备里最贵的一类损失，因为它看起来像成功打开。这条不管内容会不会被持久化，也不管完全丢失时怎么说。
机制
人重启后的第一动作是继续打字。若恢复在他们开始打之前静默写回，可能是对的；若他们已经在空白里写了新句，或另一端已经提交了更新，静默写回会消灭其中一方且不留痕迹。确认把「有一份可恢复的内容」变成一次可见的选择：时间戳、哪一端、差异摘要。选择发生在写入主文档之前。自动选「较新」在时钟漂移和部分保存下会选错；自动选「较长」会丢掉较短但正确的那次提交。
边界
只有一份内容且当前文档确实为空时，直接恢复可以不打断，但仍应在事后给出「已恢复刚才的草稿」和撤销。加密文档若无法在确认前展示明文差异，至少展示时间和来源，让人决定是否载入。自动保存非常频繁、两端内容逐字相同时，确认没有对象，不必为仪式弹窗。
怎么落地
- 检测到可恢复内容与当前打开内容不一致时，先展示差异再写入；默认不要覆盖正在编辑的缓冲区。
- 差异里写清两端的时间和来源（这台设备 / 服务器 / 另一台设备），提供保留当前、用恢复稿替换、或打开对比。
- 人已经开始在空白页打字时，把恢复稿放进待确认，而不是插入光标处。
- 验证：准备两份故意不同的稿，模拟崩溃后打开。若其中一份消失且没有选择步骤，就是静默覆盖。