监听 freeze 事件是保存状态的第一道防线，移动端浏览器在网页进入后台且内存紧张时触发该事件，此时 JS 执行暂停但 DOM 和内存保留，需立即同步保存关键状态并标记 frozen = true。
监听 freeze 事件是保存状态的第一道防线
移动端浏览器（如 Chrome Android、Safari iOS）在网页进入后台且内存紧张时，会触发 freeze 事件——这不是“页面卸载”，而是“暂停执行”，JS 定时器、fetch、requestAnimationFrame 全部停摆，但 DOM 和 JS 内存仍保留。此时必须立刻保存关键状态，否则用户切回时看到的是过期或错乱的 UI。
实操建议：
- 在
freeze回调中调用你的状态序列化函数，例如saveState()，并设置一个标记frozen = true防止重复保存 - 不要依赖
beforeunload或pagehide单独处理：它们可能不触发（比如系统直接冻结），或触发太晚（JS 已被挂起） - 避免在
freeze中做异步操作（如await localStorage.setItem()）——它可能被中断，改用同步写法或降级为sessionStorage
pagehide + event.persisted 是补漏关键
有些浏览器（尤其是 Safari）不触发 freeze，而是走 pagehide 并把 event.persisted 设为 true，表示页面将被缓存而非销毁。如果你只监听 freeze，这部分用户的状态就丢了。
实操建议：
- 在
pagehide中检查event.persisted === true，再判断frozen !== true，满足两者才执行一次saveState() - 加一层防抖：用
performance.now()记录上次保存时间，200ms 内不再重复写入，避免freeze和pagehide连续触发导致冗余操作 - 别在
pagehide里读取 DOM 状态——此时页面可能已不可见，某些元素的offsetHeight或getBoundingClientRect()返回 0
状态序列化要避开 DOM 引用和函数
saveState() 如果直接 JSON.stringify(this.state)，而 state 里存了 document.querySelector(...) 或事件处理器，会报错或序列化为空对象。移动端冻结后恢复时，这些引用早已失效。
实操建议：
- 只保存可序列化的原始值：字符串、数字、布尔、纯对象、数组；剔除
Node、EventTarget、Function类型字段 - 对表单控件状态，优先读
input.value、textarea.value、select.selectedIndex，而不是绑定到整个 DOM 节点 - 滚动位置用
window.scrollX/window.scrollY，别存element.scrollTop—— 元素可能被重建
恢复逻辑不能只靠 visibilitychange
很多人以为页面切回前台时监听 visibilitychange 就能恢复状态，但问题在于：这个事件触发时，JS 可能还没完全“解冻”，或者 DOM 尚未重绘，setState() 后 UI 不更新。
实操建议：
- 在
resume事件（如果支持）或visibilitychange后加一个setTimeout(() => { restoreState() }, 0)，让恢复逻辑进下一轮事件循环 - 恢复前先校验
document.visibilityState === 'visible'且document.hasFocus() === true，避免误恢复 - 滚动位置恢复要用
window.scrollTo({ left, top, behavior: 'auto' })——behavior: 'smooth'在冻结恢复初期可能被忽略
freeze 和 pagehide 的触发时机因浏览器而异，DOM 生命周期和 JS 执行挂起边界模糊，稍有疏忽就会出现“看起来存了，切回来却没恢复”的情况。务必在真机上用 Chrome DevTools 的 Rendering → Paint Flashing + Background throttling 模拟验证。 
