Page Lifecycle API 中 discarded 状态如何恢复页面现场

Page Lifecycle API 中的 discarded 状态是浏览器为节省资源而彻底终止页面 JS 环境的“静默杀手”——它无法被监听、无法被拦截，更不会触发任何事件，所有状态保存必须提前在 freeze 或 pagehide（persisted=true）中完成；而所谓“恢复”，实则是用户切回时基于 pageshow.persisted===false、document.wasDiscarded、localStorage 时间戳等线索识别出冷启动，并从持久化存储中主动重建现场的补救过程——理解这一点，才能真正避开“页面丢了状态却找不到原因”的陷阱。

discarded 状态无法被 JavaScript 捕获或响应，你不能监听它、不能在它发生时保存状态——所有“还原”动作，都必须基于用户重新打开页面后的上下文推断和补救。

pageshow 事件中 persisted === false 是 discard 的唯一可观察线索

当用户从任务管理器或最近任务中切回一个已被 discard 的 Tab，浏览器会发起全新导航（不是 bfcache resume），此时 pageshow 触发，且 event.persisted 为 false。这不是“没缓存”，而是“这次加载是干净的”。你需要交叉验证：

• 检查 document.wasDiscarded 是否为 true（仅首次 JS 执行时有效，刷新即失效）
• 读取 localStorage 中上次保存的时间戳，若距当前时间 > 5 分钟，discard 概率极高（freeze 通常撑不过 2–3 分钟）
• 检查 URL 是否含 ?_reloaded=1 这类标记（需你在上一次 pagehide 或 freeze 中主动写入）
• 用 performance.getEntriesByType('navigation')[0]?.type 判断是否为 'navigate' 或 'reload'，二者均可能对应 discard 后重建

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

discard 不可逆，所以“还原”的前提是“之前已存好”。可靠保存时机只有两个：

• freeze 事件：JS 尚未终止，DOM 可读，是最后同步写入机会；应立刻调用 saveState() 并设标记 frozen = true
• pagehide 事件且 event.persisted === true：Safari 等浏览器可能跳过 freeze，直接走 bfcache 路径，此时需补漏保存（但要先判断 frozen !== true，避免重复）

保存操作必须同步、轻量：localStorage.setItem() 或 sessionStorage.setItem() 是首选；避免 indexedDB（异步可能中断）、避免 navigator.sendBeacon()（freeze 中不一定发出）。

还原逻辑必须严格区分冷启动与热恢复

用户回到页面时，你要立刻判断本次加载类型：

• 冷启动（discard 后重建）：pageshow.persisted === false + document.wasDiscarded === true + document.hasFocus() === true + DOM 状态为空白 → 从 localStorage 或服务端拉取快照，手动 restore 表单值、window.scrollX/window.scrollY、选中项等
• 热恢复（bfcache resume）：pageshow.persisted === true → 不需要重载数据，但需检查定时器是否续上、网络请求是否卡住、UI 是否错乱；此时不应清空旧状态，更不能 reload 页面

关键细节：还原时不要依赖 visibilitychange 或 focus，它们在 discard → reload 过程中不触发或延迟；也不要尝试读取旧 DOM 节点（已被销毁），只操作原始值。

最容易被忽略的一点：discarded 状态下，页面 JS 环境彻底终止，连 beforeunload 都不会触发。所谓“还原”，本质是一次带上下文的冷启动重建——你得把 save 和 restore 当作一对原子操作来设计，而不是指望某个事件兜底。

以上就是《Page Lifecycle API 中 discarded 状态如何恢复页面现场》的详细内容，更多关于的资料请关注golang学习网公众号！