无法异步判定页面被丢弃的具体成因；discard是js环境立即终止的终态，无事件回调，唯一可靠干预点是freeze和pagehide(persisted=true)事件中同步保存状态。

你无法通过 Page Lifecycle API 异步判定页面进入“被丢弃（discarded）”状态的具体成因。

discarded 状态本身不可捕获

当浏览器决定丢弃页面时，JS 执行环境被立即终止：所有定时器清空、网络请求中断、事件监听器失效、beforeunload 和 pagehide 均不触发。这不是一个可监听的生命周期事件，而是一个终态结果——没有回调、没有钩子、没有异步机会。

所谓“判定成因”，只能在用户**重新打开该 Tab 后**，通过加载上下文线索进行事后推断，而非实时或异步检测。

唯一可用的线索来自 pageshow 事件

页面被 discard 后重建，会触发 pageshow，此时可观察以下组合信号：

• event.persisted === false：说明不是从缓存恢复，是一次全新加载
• document.wasDiscarded === true：仅在首次 JS 执行时为真，是最直接证据
• performance.getEntriesByType('navigation')[0]?.type 为 'reload' 或 'navigate'：配合时间差，支持 discard 推断
• 检查 localStorage 中保存的时间戳：若距当前超过 5 分钟，大概率已 discard（Frozen 通常只维持 2–3 分钟）
• URL 是否含人工标记（如 ?_reloaded=1）：需上一次 freeze 或 pagehide 时主动写入

真正可控的时机只有 freeze 和 pagehide(persisted=true)

想保住现场，必须在 discard 发生前完成状态保存。可靠干预点仅有两个：

• freeze 事件：页面即将冻结，DOM 可读、JS 尚未挂起，是同步保存状态的最后机会
• pagehide 且 event.persisted === true：Safari 或部分 WebView 的兜底路径，用于补漏

二者都应使用 { once: true } 绑定，避免重复执行；保存操作需同步、轻量，禁用 fetch、setTimeout、DOM 修改等高风险调用。

discard 的常见诱因只能归类，无法精确识别

根据设备与场景，可大致归因于以下三类：

• 内存严重不足：低端 Android 设备后台 Tab 过多，浏览器主动回收长时间冻结的页面
• 进程被系统强制终止：iOS 后台长时间未响应，或电池优化策略 kill WebView 进程
• 用户主动清理：从任务管理器滑掉 Tab、使用“清除所有标签页”功能

这些原因无法通过 JS 区分，只能结合设备 UA、运行时内存信息（navigator.deviceMemory）、后台驻留时长等辅助判断，但均非确定性依据。

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