Page Lifecycle API异步捕捉系统回收与用户输入还原

在移动设备或资源受限的环境中，浏览器为节省内存，可能会主动冻结或丢弃长时间处于后台的页面。这带来了一个核心问题：当页面被系统“回收”时，能否像处理正常关闭一样，优雅地保存用户输入？答案可能与直觉不同。

简单来说，你无法真正“捕捉”到页面被丢弃的瞬间。因为一旦浏览器决定丢弃页面，它会直接终止该页面的整个 JavaScript 执行环境。这意味着所有事件监听器、定时器、网络请求，甚至是我们寄予厚望的 beforeunload 事件，都不会触发。因此，所谓的“捕捉回收”，本质是在系统动手之前，利用最后的安全窗口保存数据，并在页面再次加载时，通过一系列信号交叉验证，来推断并还原用户状态。

真正可靠的保存时机，只有这两个

既然无法在“死亡”时保存，就必须在“冻结”前行动。有两个事件是 JavaScript 能安全执行并持久化数据的最后窗口：

• freeze 事件：当页面即将进入冻结状态时触发。此时 DOM 仍然可读，JavaScript 也能执行写入操作，是保存表单草稿、滚动位置、当前选中状态等关键输入信息的首选时机。
• pagehide 事件，且 event.persisted === true：这个信号表明页面将被放入“往返缓存”或进入冻结状态，后续有可能直接恢复。它可以作为 freeze 事件的兜底方案，确保数据被同步保存。

需要警惕的是，不要过度依赖 visibilitychange 或 blur 事件。它们只反映页面的可见性或焦点变化，与系统是否决定冻结、丢弃页面没有直接因果关系，中间存在不可控的时间空窗期。

保存什么？轻量、可序列化、带上时间戳

在冻结阶段，浏览器不允许发起新的网络请求，也不能操作 DOM，复杂对象和函数更是无法存储。因此，保存策略必须精简：

• 只存用户可见的关键输入：例如 textarea 和 input 的当前值、下拉菜单的选中项、窗口的滚动位置等。
• 优先使用 sessionStorage：相比 localStorage，它的生命周期更贴合单页会话，通常在关闭标签页后自动清理，更适合存储临时草稿。
• 务必附带时间戳：存储的数据结构建议像 { draft: "...", sa vedAt: Date.now() } 这样。这个时间戳是后续判断数据是否过期的关键依据。
• 敏感信息不上报：密码、令牌等敏感字段不建议本地存储。恢复时，应通过服务端进行校验和重新获取。

如何判断页面是被“丢弃”后冷启动的？

当用户再次切换回标签页时，如果页面已被丢弃，浏览器会进行一次全新的加载。此时，你需要结合多个信号来交叉验证，才能做出相对准确的判断：

• pageshow 事件中的 event.persisted === false：这是一个基础信号，但请注意，普通的页面刷新也会满足这个条件。
• 检查 URL 中的标记参数：例如，可以在上一次冻结时，将当前 URL 加上类似 _reloaded=1 的参数并执行一次 location.replace()。加载时检查该参数是否存在。
• 对比 sessionStorage 中的时间戳：如果存储的时间戳距离当前时间超过5分钟，那么页面很可能已经被丢弃了（因为冻结状态通常只能维持2-3分钟）。
• 利用 Performance Na vigation API：检查 performance.getEntriesByType('na vigation')[0].type 的值是否为 'na vigate' 或 'reload'，并结合其他上下文线索进行判断。

还原策略：冷启动与热恢复必须区别对待

识别出场景后，还原逻辑不能一刀切。不同的恢复路径，对应着完全不同的处理策略：

• 冷启动（Discard 后的重建）：DOM 是全新渲染的，页面通常会自动获得焦点（document.hasFocus() === true），所有之前的 JavaScript 状态都已丢失。这时，你需要从 sessionStorage 中取出快照，手动还原表单值、滚动位置、激活的选项卡等。
• 热恢复（从 Frozen 或 bfcache 中恢复）：DOM 和大部分 JavaScript 状态都被保留了下来。此时，pageshow 事件的 persisted 属性为 true，或者会触发 resume 事件。这种情况下，不要重新填充表单，以免覆盖用户可能刚刚输入的新内容。你应该做的是检查并重新连接中断的网络请求、重置失效的定时器、更新倒计时等动态UI状态。

最后，一个实用的建议是：在成功还原状态后，及时清除旧的快照数据，避免下次加载时误用。对于还原操作本身，可以加入简单的节流逻辑（例如200毫秒内不重复执行），以防止某些事件被多次触发导致的问题。