H3.09.1recover uncommitted work after interruption设计研究
意外中断后需恢复未提交内容
别名: 崩溃恢复 · 断网恢复 · crash recovery
概念解释
进程被杀、浏览器崩溃、网络在提交前断开，人以为还在编辑的内容其实只活在即将消失的内存里。恢复未提交内容指中断之后，这些尚未成为正式记录的输入还能回来。这条只管「要能回来」，不管回来时要不要人点头，也不管彻底没了该怎么说。它也不是表单里那套正在进行的自动保存节奏本身。
机制
未提交内容的寿命绑在易失层：输入框、本地草稿、未应答的请求。中断切断的是进程或通道，不是人的意图。人重启后会用「我写到哪」去对世界，世界若是空的，损失不可见地发生在中断那一刻，发现却在几分钟之后。恢复要把易失层在中断前搬到仍活着的存储：本地持久化、到达服务器的草稿、可重放的请求。搬的粒度要够小，一次按键或一次停顿就该有机会被留下，否则「恢复」只覆盖早几分钟的版本，最近打的字仍然死了。
怎么研究
在编辑任务中注入杀进程、关页、断网，比较有无中断前持久化。
自变量：持久化间隔、存储位置（仅内存 / 本地 / 已达服务器）、中断类型。 因变量：恢复后与中断前内容的差异、发现损失的时间、是否重打已经写过的段落。
实验室里的中断是预告的，人会提前保存。更硬的做法是在他们以为任务还在继续时杀进程。不要只测「有没有恢复提示」，要逐字比对。
边界
敏感字段（密码、一次性验证码、支付要素）不应进入可恢复层，中断后空着是故意的。只读浏览没有未提交内容可恢复。多人正在编同一段时，本地恢复可能与他人已提交的版本冲突，那是下一步要人确认的问题，但「有东西可恢复」这一层仍要先成立。只在内存里的「恢复」在杀进程后等于没有。
怎么落地
- 对长输入在停顿后写入本地或草稿接口，间隔短到一次中断只会丢掉最后几个词，而不是整段。
- 提交中的请求记下幂等键和载荷，重连后可查询或安全重放。
- 密码类字段排除在可恢复存储之外。
- 验证：写一段不可从别处复制的文字，强制杀应用再打开，逐字对比。缺的若超过最后一次明显停顿，持久化间隔就太长。