PageLifecycleAPI页面回收预判技巧

本文深入解析了如何在浏览器页面被回收前精准捕获保存时机，指出“discarded”状态本身无法被JavaScript监听，真正可靠的操作窗口仅有两个：`freeze`事件（页面冻结前的最后可执行机会）和`pagehide`事件中`event.persisted === true`的场景；文章强调必须用一次性监听、同步保存序列化数据、规避DOM引用与异步操作，并揭示仅靠`pageshow.persisted`无法准确区分冷启动与热恢复，需结合localStorage时间戳、导航类型等多维度判断，为开发者提供了一套兼顾兼容性、健壮性与性能的页面状态持久化实战方案。

页面被强制回收（discarded）本身无法被捕获——JS 执行环境已彻底终止，任何监听器、定时器、beforeunload 都不会运行。所谓“前兆”，实际只有两个可编程干预点：freeze 事件和 pagehide 且 event.persisted === true。错过它们，就等于放弃保存机会。

freeze 事件是唯一真正可靠的“冻结前哨”

这是页面进入 Frozen 状态前最后一个 JS 可执行的时机，DOM 可读、内存未清空、异步任务尚未被挂起。它不是“可能冻结”，而是“即将冻结”的明确信号。

• 必须用 addEventListener('freeze', handler, { once: true })，避免重复绑定或泄漏
• 在此回调中同步调用状态保存函数，例如 saveFormDraft()、saveScrollPosition()
• 不要发起新 fetch 或 setTimeout——这些调用大概率被静默丢弃
• 慎用 localStorage.setItem() 异步写法；若担心阻塞，可用 sessionStorage 降级，或提前在 visibilitychange 中预热写入权限

pagehide + event.persisted === true 是 Safari 和部分 Android WebView 的兜底路径

Safari iOS（尤其旧版本）和某些定制 WebView 可能跳过 freeze，直接走 pagehide 并设 event.persisted === true，表示页面将被缓存而非销毁。只监听 freeze 会漏掉这部分用户。

• 在 pagehide 回调中先判断 event.persisted === true，再检查是否已由 freeze 处理过（例如用 window.__savedOnFreeze = true 标记）
• 若未保存过，立即执行一次 saveState()；但需加时间防抖，比如 performance.now() - lastSaveTime > 200
• 避免在 pagehide 中读取 DOM 布局信息（如 getBoundingClientRect()），此时元素可能已不可测量

保存内容必须可序列化，且避开 DOM 引用和函数

冻结后恢复时，所有 DOM 节点引用、事件处理器、Promise 实例都已失效。强行保存会导致还原时报错或数据为空。

• 只保留原始值：字符串、数字、布尔、纯对象、数组；用 JSON.stringify() 前先 delete 掉 state.ref、state.handler 类字段
• 表单状态读 input.value、textarea.value、select.selectedIndex，而不是存整个 input 元素
• 滚动位置用 window.scrollX / window.scrollY，别存 element.scrollTop —— 元素重建后该值无意义
• 时间戳建议用 Date.now()，不用 new Date().toISOString()（多占字符，无额外收益）

最容易被忽略的是：你永远无法在 pageshow 中区分“冷启动”和“热恢复”仅靠 event.persisted。它为 false 只说明这次不是从 bfcache 恢复，但可能是 discard 后重建，也可能是用户手动刷新。得结合 localStorage 时间戳、URL 参数标记、performance.getEntriesByType('navigation')[0]?.type 综合判断——否则还原逻辑会把刷新当成丢弃，错误拉取旧快照。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~