编辑中意外退出需要保留草稿而非丢弃改动
别名: 崩溃草稿 · 意外退出恢复 · crash recovery draft
概念解释
编辑态里的改动若还没成为当前正式稿，进程被杀、浏览器崩、断网、系统把标签丢掉，都属于意外退出。这时应留下一份可恢复的草稿，下次打开同一对象时让人确认后接上，而不是当作从未改过。它针对的是非自愿中断。人自己点返回时要不要问一句，是主动离开；表单自动保存的频率与可见状态，是草稿机制的另一层。这里只问：编辑态被系统打断之后，活有没有丢。
机制
意外退出不给决策时间。不能靠离开确认，因为没有「离开」这个动作。唯一扛得住的是在中断前就已经把差额写到可复活的存储里。若只存在于内存，杀进程等于删稿。恢复必须让人看见并确认：静默把草稿盖到正式稿上，会在「我已经在别的设备改过」时造成覆盖；静默丢掉，人以为产品吞了工作。打开时并排或提示「发现未保存的编辑」把选择权给人。草稿还要绑在同一对象和同一身份上，绑错就会把甲的未完成句写进乙打开的文档。超时过短的草稿（几分钟就过期）对崩溃后隔几小时才回来的人等于没有。
怎么研究
在编辑态改一段落后强制杀进程或断网，再打开同一对象。比较：无草稿、有草稿静默覆盖、有草稿需确认。
自变量：草稿写入时机（击键 / 定时）、恢复是否确认、是否标明草稿时间。 因变量：中断后改动找回率、错误覆盖正式稿的次数、把别人草稿当成自己的次数。
实验室杀进程比真实崩溃干净，但要包含「隔一段时间再打开」。不要和主动点返回的提示混测。多设备：手机上的草稿与桌面正式稿冲突时，看确认是否出现。
边界
每键已同步到服务器的文档，意外退出本来没有差额，恢复提示是噪音。敏感字段（密码、支付）不应进草稿。只读查看被杀进程，没有编辑差额。协作中对方已把同一段改成别的，恢复草稿变成冲突，应走冲突选择，而不是把本地草稿强行盖上。无存储权限的隐私模式，要在进入编辑时说明「关闭窗口将丢失」，而不是假装有草稿。
怎么落地
- 编辑态期间把差额定时写入绑定到该对象与该账号的草稿；意外退出后再次打开时提示「有未保存的编辑」，展示时间，让人恢复或丢弃。
- 禁止静默用草稿覆盖已经更新过的正式稿。
- 草稿保留窗口以小时或天计，并在提示里写还剩多久。
- 验证：改一段落后强制结束进程，再打开。人应看到带时间的恢复选择，选恢复后文字还在。再在另一端先改正式稿，看恢复是否变成确认而不是覆盖。