page lifecycle api 的 freeze 事件是 pwa 后台冻结前唯一可靠信号，必须监听以同步释放定时器、abort fetch、解绑 requestidlecallback；pagehide 的 persisted 属性仅作补救判断，visibilitychange 不代表冻结，document.wasdiscarded 仅恢复瞬间有效。

Page Lifecycle API 是 PWA 在后台被冻结或丢弃时唯一能靠得住的信号源；不监听 freeze，就等于放弃主动清理机会，后续卡顿、内存泄漏、请求残留全都会找上门。

必须监听 freeze 做即时资源释放

页面进入 Frozen 状态前，freeze 是最后一个能同步执行 JS 的时机：DOM 还可读、定时器还没停、fetch 仍可 abort——但之后所有异步任务（包括 setTimeout、requestIdleCallback）都会被挂起或丢弃。

• 用 addEventListener('freeze', handler, { once: true }) 绑定，避免重复触发
• 立刻清除所有活跃定时器：clearInterval、clearTimeout
• 取消未完成的 fetch 请求：检查是否已创建 AbortController，调用 abort()
• 解除 requestIdleCallback 回调（如有），避免恢复后意外执行
• 不要在此时发起新请求、修改 DOM 或写入 localStorage——浏览器可能已开始冻结流程，这些操作会被静默忽略

pagehide 的 event.persisted 不是“缓存标志”，而是补救开关

pagehide 本身不区分用户离开还是系统冻结，关键看 event.persisted：

• 为 true：说明页面可能被 bfcache 或 Frozen，但 freeze 未必已触发（尤其某些 Android WebView 不发该事件）→ 此刻要补做一次资源清理
• 为 false：大概率是正常卸载（Terminated），可跳过状态保存，专注释放（如删掉临时 localStorage 键）
• Safari 在部分 iOS 版本中对 persisted 返回不稳定，建议叠加判断：document.visibilityState === 'hidden'

别把 visibilitychange 当成冻结信号

visibilitychange 只反映页面是否在前台可见，和系统是否冻结无关：

• 桌面多窗口切换时，visibilityState 可能长期为 'hidden'，但页面完全没被冻结
• iOS Safari 某些后台场景下，页面甚至在 visibilityState === 'visible' 时就被突然冻结
• 仅适合轻量操作：暂停 video、停掉 Canvas 动画；不要在这里触发 heavy cleanup，容易误杀正在运行的逻辑
• 真正可靠的冻结信号只有 freeze；其他事件都是辅助，不是替代

document.wasDiscarded 只在恢复瞬间有效，且只读一次

document.wasDiscarded 是个只读布尔值，仅在页面从 Discarded 状态恢复后的**首次 JS 执行时**为 true：

• 它不是实时状态标识，不能轮询，也不能在 DOMContentLoaded 后再查——那时值已重置为 false
• 适合用于恢复逻辑：比如重载关键状态、重建 WebSocket 连接、重置全局计数器
• 不能用来判断“当前是否被丢弃”，因为丢弃发生时 JS 已终止，根本没机会读这个值
• 注意：它和 freeze、pagehide 完全不同生命周期，不要混用场景

最易被忽略的一点：PWA 的 Service Worker 虽然能接管网络请求，但它无法感知页面是否被冻结；freeze 必须在主页面 JS 中监听并响应。一旦漏掉这个事件，用户切回标签页时看到的可能是卡死界面、重复请求、或残留的 loading 状态——而这些问题，在开发阶段几乎无法复现。

大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！