A5.08.2State preservation for interruption recovery设计
系统应保留中断前的状态与位置
别名: session restoration · context preservation · 状态保留 · 断点续做
概念解释
用户被中断后回到系统里，界面应该原样停在离开时的位置——滚动到的地方、填了一半的表单、展开的面板、正在编辑的那一行——而不是重置到默认状态要求用户重新找回。这条讲的是一项具体的系统职责：状态保留（state preservation），把恢复原任务所需的部分线索从用户的头脑里搬到界面上。
它不是锦上添花的体验细节，而是直接针对恢复成本里"重建目标状态"这部分下的手：用户需要重建的信息越多，恢复越慢、越容易出错；系统能替用户记住的部分，就不需要用户自己重新想起来。
机制
恢复原任务时最耗时的一步，是把散落的进度信息重新拼回工作记忆——刚才滚动到哪、填到哪一步、上一步的判断依据是什么。这些信息如果只存在于用户自己的记忆里，中断发生后很容易被新任务的信息覆盖或冲淡，恢复时必须依靠回忆或重新翻找来补全。
系统保留状态相当于把这部分信息从内部记忆转移到外部环境——只要界面把离开时的位置、输入内容、展开状态原样呈现出来，用户不需要凭记忆重建这些细节，只需要"看一眼就知道刚才做到哪"，重建的负担直接从记忆检索降级为知觉确认，两者所需的时间和出错概率完全不在一个量级上。
这也解释了为什么"记住滚动位置"和"记住表单里未提交的输入"看似是两个不同的技术实现，本质上做的是同一件事：把恢复原任务目标状态所需的线索预先摆在用户能看到的地方。
边界
- 只能覆盖恢复代价里"重建目标状态"这一部分。 恢复成本里另一部分——记得自己还欠着一个被中断打断的次要任务——不属于状态保留能解决的范围，那需要主动的提醒机制，而不是被动的位置还原。
- 保留的信息越多，界面本身的复杂度和存储成本越高。 不是所有状态都值得保留，保留粒度要按恢复时用户真正会依赖的线索来定，不必对每一个像素级细节都做持久化。
- 中断时间跨度极短（几秒内的应用内切换）时，状态保留的收益不明显，因为工作记忆本身还没来得及丢失这些信息，此时的恢复代价主要来自别处。
- 多设备或多会话场景下，状态保留依赖同步机制本身的可靠性——如果状态没能及时同步到用户实际使用的设备上，保留了也等于没保留。
怎么落地
- 保留的范围要覆盖用户实际用来判断"做到哪"的所有线索：不只是滚动位置，还包括展开/折叠状态、当前选中项、未提交的表单输入、多步骤流程里已完成的步骤标记。
- 恢复后的呈现要让用户无需操作就能确认状态：回到页面时如果需要用户手动滚动、手动展开才能看到刚才的位置，等于只做了一半，用户仍然要花额外步骤自己找回上下文。
- 对多步骤任务，保留的不只是最后一屏，还要保留"已完成到第几步"这个进度信息，让用户不需要靠记忆判断接下来该做什么。
- 状态保留的持续时间要匹配典型的中断时长：如果只在应用内切换的几秒内有效，遇到跨天的中断（用户几天后才回来）状态已经丢失，等于中断代价最高的场景反而得不到保护。
- 验证办法：让用户完成一个多步骤任务，在不同阶段人为制造中断（切换应用、关闭页面重新打开），检查恢复后界面呈现的信息是否足以让用户不查看历史记录或不重新操作就能判断刚才做到哪一步；做不到的地方就是状态保留的缺口。