PageLifecycleAPI中discarded状态恢复方法解析

Page Lifecycle API 中的 discarded 状态本质是浏览器强制终止 JS 引擎后的“静默销毁”，无法监听、无法拦截，所有试图绑定 discarded 事件的代码均无效；真正的现场还原并非实时响应，而是依赖 freeze 和 pagehide（persisted=true）这两个唯一安全时机提前将关键状态（如滚动位置、表单数据、播放进度）序列化存入 sessionStorage 或 localStorage，并在 pageshow 阶段通过组合判断 document.wasDiscarded、event.persisted 和 navigation type 精准识别冷启动，再结合时间戳校验避免旧快照污染，从而实现看似无缝的页面恢复——这是一场在 JS 生死边界上精心设计的“预防-保存-推断-重建”协作，尤其在 iOS 和安卓定制系统中更需真机覆盖多场景验证，稍有疏漏便会丢失用户最后的操作痕迹。

discarded 不是事件，而是 reload 后的上下文线索

用户切回一个已被 discard 的 Tab 时，浏览器会发起全新导航（等价于手动刷新），此时唯一可依赖的信号来自 pageshow 事件：
– event.persisted === false（这是必要但不充分条件）
– document.wasDiscarded === true（仅首次 JS 执行时有效，刷新后即失效）
– performance.getEntriesByType('navigation')[0]?.type 为 'reload' 或 'navigate'，且无前序 pagehide with persisted === true
需组合判断，单靠某一项容易误判（比如用户真手点了刷新，persisted 也是 false）。

真正能保存状态的只有 freeze 和 pagehide(persisted=true)

想保住现场，必须在页面被冻结前完成持久化。这两个时机是唯二安全窗口：
– freeze 事件：JS 仍可执行，但最多运行 500ms，禁止新 fetch，只能复用已有连接
– pagehide 事件且 event.persisted === true：说明即将进 bfcache，大概率 resume，也应保存
保存动作建议：

• 用 localStorage.setItem() 存轻量 JSON（如当前 tab ID、表单值、滚动 offset）
• 避免 navigator.sendBeacon()：在 freeze 中不一定发出，尤其弱网下
• 加时间戳防旧快照污染：存入时写 lastSaved: Date.now()，恢复时比对是否超 10 分钟

还原时必须区分冷启动与热恢复

用户回到页面后，立即检查加载类型：
– 若 pageshow.persisted === false 且 document.wasDiscarded === true → 极大概率是 discard 后冷启动，需从 localStorage 拉快照并手动 restore UI（滚动位置、输入框 value、播放进度等）
– 若 pageshow.persisted === true → 是 bfcache resume，DOM 和 JS 状态基本 intact，只需补发未完成请求或重置失效定时器
注意：document.hasFocus() 在 resume 初期可能为 false（尤其移动端锁屏后），别把它当唯一判断依据。

移动端和 iOS 的兼容性陷阱

iOS Safari 几乎不触发 freeze，常直接跳到 discarded；三星/华为定制 Android 可能截断 freeze 事件。因此：
– 必须双监听：freeze + pagehide（带 persisted 判断）
– 用 sessionStorage 替代 localStorage 更稳妥（单页会话生命周期匹配度更高）
– 真机测试不能只切 Tab，要覆盖锁屏、通知栏下拉、最近任务切换等后台场景
– 不存函数、DOM 节点、WebSocket 实例——这些不可序列化，JSON.stringify() 会静默丢弃

以上就是《PageLifecycleAPI中discarded状态恢复方法解析》的详细内容，更多关于的资料请关注golang学习网公众号！