freeze是唯一可靠的同步存盘时机，因其在JS被硬性挂起前提供最后一个可执行钩子，能安全调用localStorage.setItem()；visibilitychange和beforeunload则因冻结时JS直接停摆而不可靠。
移动端页面退到后台后被冻结，freeze 事件是唯一能**同步写入、不被中断**的状态存盘时机；依赖 visibilitychange 或 beforeunload 必丢数据，尤其在 iOS Safari 和国产安卓浏览器上几乎无效。
为什么 freeze 是唯一可靠的静默存盘入口
系统冻结页面时，JS 执行会被硬性挂起——定时器停摆、异步任务中断、DOM 不可读。但 freeze 事件是在冻结前**最后一个可同步执行 JS 的钩子**，此时 localStorage.setItem() 还能成功落盘，且不会被中断。
- 常见错误现象：
visibilitychange触发后刚调用JSON.stringify()，JS 就被挂起，状态根本没存上 - 不要尝试在
freeze中做await fetch()或indexedDB.put()：这些异步操作大概率被截断，且无回调机会 - 必须加
{ once: true }：避免重复绑定导致多次触发，尤其和pagehide兜底逻辑共存时 - iOS Safari 直到 16.4+ 才稳定支持
freeze，旧版本会静默忽略，所以不能只靠它
pagehide + persisted 是 freeze 的必要补漏
pagehide 本身不表示冻结，但当 event.persisted === true 时，说明浏览器打算缓存或冻结该页面——这是 Android Chrome 和部分 Safari 版本的“替代路径”，错过就等于放弃这部分用户。
- 必须配合防重机制：用闭包变量（如
frozen = false）标记是否已存盘，防止freeze和pagehide连续触发两次 - 别在
pagehide回调里读取element.scrollHeight或getBoundingClientRect()：此时元素可能已脱离布局流，返回0 - 节流很重要：用
performance.now()记录上次保存时间，200ms 内不再触发第二次写入，避免冗余 I/O
状态序列化必须轻量、可 JSON 化、无副作用
冻结前存的数据，恢复时要能原样解析并安全使用。任何不可序列化字段（如函数、DOM 节点、undefined）都会让 JSON.stringify() 抛错，直接退出事件处理器，导致存盘失败。
- 只保留原始值：
window.scrollY、input.value、select.selectedIndex、new Date().toISOString() - 剔除敏感字段：token、临时密钥、未加密的用户身份信息——
resume时应走服务端校验，而非本地还原 - 优先用
sessionStorage：比localStorage更贴合单页会话生命周期，避免跨会话污染 - 必须包
try/catch：捕获JSON.stringify()失败或setItem()配额超限，catch 块里不要throw，否则阻断冻结流程
resume 事件里只能做轻量校验与补救
resume 不是页面重启，而是“时钟恢复”：所有定时器 ID、未 resolve 的 Promise、事件监听器都还在，只是时间暂停了。把它当初始化入口，必然引发重复请求、双重绑定、UI 状态错乱。
- 先校验再动：检查
document.visibilityState === 'visible' && document.hasFocus()，确认用户真正在前台 - 只重置失效逻辑：比如重新
setTimeout轮询、检查fetch是否超时、手动设置window.scrollTo() - 别在
resume中批量读取 localStorage 并立即渲染：可能触发 layout thrashing，尤其 DOM 还没 fully ready 时 - 恢复后立即
removeItem()：避免下次打开页面（非 resume 场景）又误恢复旧状态
真正难的不是写对这四个事件，而是接受一个事实：你无法阻止系统杀进程，freeze 和 resume 只在浏览器还给你留着内存时才存在；一旦 Android 厂商 ROM 直接销毁 WebView 进程，所有 JS 生命周期事件都归零——这时候得靠原生层保活或 JSBridge 同步，而不是在网页里反复加固 freeze 回调。
