discarded 状态无法被监听，因其发生时 js 引擎已终止；还原依赖 freeze/pagehide 保存状态 + pageshow 时结合 document.wasdiscarded、persisted 和 navigation type 综合判断冷启动并恢复。
discarded 状态本身**无法被监听或响应**，你写再多 addEventListener('discarded', ...) 都不会执行——浏览器在进入该状态时已彻底终止 JS 引擎，所有代码、定时器、网络请求、甚至 beforeunload 都不触发。所谓“还原 discarded 页面现场”，本质是**提前预防 + 事后推断 + 条件恢复**。
discarded 不是事件，而是 reload 后的上下文线索
用户切回一个已被 discard 的 Tab 时，浏览器会发起全新导航（等价于手动刷新），此时唯一可依赖的信号来自 pageshow 事件：
– event.persisted === false（这是必要但不充分条件）
– document.wasDiscarded === true（仅首次 JS 执行时有效，刷新后即失效）
– performance.getEntriesByType('navigation')[0]?.type 为 'reload' 或 'navigate'，且无前序 pagehide with persisted === true
需组合判断，单靠某一项容易误判（比如用户真手点了刷新，persisted 也是 false）。
真正能保存状态的只有 freeze 和 pagehide(persisted=true)
想保住现场，必须在页面被冻结前完成持久化。这两个时机是唯二安全窗口：
– freeze 事件：JS 仍可执行，但最多运行 500ms，禁止新 fetch，只能复用已有连接
– pagehide 事件且 event.persisted === true：说明即将进 bfcache，大概率 resume，也应保存
保存动作建议：
- 用
localStorage.setItem()存轻量 JSON（如当前 tab ID、表单值、滚动 offset） - 避免
navigator.sendBeacon()：在freeze中不一定发出，尤其弱网下 - 加时间戳防旧快照污染：存入时写
lastSaved: Date.now()，恢复时比对是否超 10 分钟
还原时必须区分冷启动与热恢复
用户回到页面后，立即检查加载类型：
– 若 pageshow.persisted === false 且 document.wasDiscarded === true → 极大概率是 discard 后冷启动，需从 localStorage 拉快照并手动 restore UI（滚动位置、输入框 value、播放进度等）
– 若 pageshow.persisted === true → 是 bfcache resume，DOM 和 JS 状态基本 intact，只需补发未完成请求或重置失效定时器
注意：document.hasFocus() 在 resume 初期可能为 false（尤其移动端锁屏后），别把它当唯一判断依据。
移动端和 iOS 的兼容性陷阱
iOS Safari 几乎不触发 freeze，常直接跳到 discarded；三星/华为定制 Android 可能截断 freeze 事件。因此：
– 必须双监听：freeze + pagehide（带 persisted 判断）
– 用 sessionStorage 替代 localStorage 更稳妥（单页会话生命周期匹配度更高）
– 真机测试不能只切 Tab，要覆盖锁屏、通知栏下拉、最近任务切换等后台场景
– 不存函数、DOM 节点、WebSocket 实例——这些不可序列化，JSON.stringify() 会静默丢弃
discarded 的不可监听性决定了：所有“还原”逻辑都建立在「上一次冻结前有没有存对」和「这一次 reload 后有没有认准」之上。最容易被忽略的是时间戳校验和 document.wasDiscarded 的一次性特征——它只在首个脚本执行周期可见，错过就永远失去这条关键线索。大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
