pagehide能替代unload，但必须结合event.persisted判断：persisted===true表示页面将进入bfcache，不应保存；false才是最后保存时机，否则会导致多存、错存或漏存。
pagehide 能替代 unload，但必须配合 event.persisted 判断，否则反而会多存、错存、漏存。
为什么不能直接把 unload 逻辑搬进 pagehide
直接把原来写在 unload 里的保存逻辑复制到 pagehide 回调里，会导致：页面每次被放入 bfcache（比如 iOS Safari 切后台、Android Chrome 按返回键）都执行一次保存，覆盖掉用户正在编辑的草稿；而真正要销毁时（如关闭 Tab、跳转外链），又可能因冻结提前发生而没机会运行。
根本原因是：pagehide 触发不等于页面要消失——它只是“即将隐藏”，event.persisted 才告诉你浏览器到底打算缓存还是丢弃。
-
event.persisted === true：页面将进 bfcache，DOM 和 JS 上下文保留，后续pageshow会秒恢复，此时不该清理、不该上报、不该覆盖草稿 -
event.persisted === false：页面真要卸载了，这才是你最后的保存窗口
如何用 pagehide + persisted 正确触发状态存盘
只在 event.persisted === false 时执行关键保存动作，其他情况跳过。同时建议加一层 document.visibilityState === 'hidden' 防误触（Safari 有时在 App 切后台就发 pagehide，但 visibility 还是 visible）。
function handlePageHide(event) {
if (event.persisted || document.visibilityState !== 'hidden') return;
saveDraft(); // 你的业务存盘逻辑
navigator.sendBeacon('/log', JSON.stringify({ action: 'leave' }));
}
window.addEventListener('pagehide', handlePageHide);
注意：saveDraft() 必须是轻量同步操作；避免 fetch 或 localStorage.setItem 大对象（iOS Safari 冻结后可能静默失败）；优先用 sendBeacon 发送小数据。
为什么还要监听 freeze 事件
freeze 比 pagehide 更早、更确定地表示“JS 即将暂停”。iOS Safari 和新版 Chrome 会在 pagehide 前先触发 freeze，错过它就等于放弃最早的机会。
- 在
freeze中立即调用saveDraft()，并设标记frozen = true - 在
pagehide中补检查：!frozen && !event.persisted，确保 freeze 未触发的边界情况也被覆盖 - 不要在
freeze里做异步、DOM 操作或弹窗——全无效
常见坑点和兼容性提醒
这些细节不处理，pagehide 就会退化成另一个 unreliable 的 unload：
- 别用
window.onpagehide = handler—— 只能绑定一个，推荐统一用addEventListener('pagehide', ...) - SPA 场景下，路由跳转不会触发
pagehide，它只管整个页面生命周期；组件级清理该用onUnmounted或beforeRouteLeave - Chrome Android 和 Safari iOS 对
pagehide触发时机不一致：Safari 更激进，可能在用户还没松手就触发；Chrome 更保守，但 bfcache 行为受Cache-Control响应头影响 -
sendBeacon是目前唯一被广泛支持的“卸载前可靠发送”机制，但它只支持 POST、不支持自定义 header、payload 限制约 64KB
真正难的不是监听哪个事件，而是判断「此刻页面到底算不算真正离开」——persisted 是钥匙，visibilityState 和 freeze 是保险栓，少一个都容易漏。
