pagehide 是移动端唯一可靠的退出埋点入口，需结合 event.persisted === false 和 visibilityState === 'hidden' 判断真卸载，并用 sendBeacon 发送数据，同时监听 freeze 事件防漏报。
pagehide 是目前在移动端实现可靠退出埋点的唯一可行入口，unload 在 iOS Safari 和微信 WebView 中基本不触发或被静默忽略，强行用它会导致大量埋点丢失。
为什么 unload 在移动端完全不可靠
现代移动端浏览器（Chrome Android、Safari iOS、微信内置 WebView）普遍启用 bfcache（back/forward cache），用户按返回键、切后台、甚至从微信跳转到其他小程序时，页面常被冻结而非销毁。unload 一触发，bfcache 就失效，导致后续返回必须重刷；更关键的是，它在 iOS Safari 中根本不会执行异步逻辑（比如 fetch 或 XMLHttpRequest），连 sendBeacon 都可能被跳过。
-
beforeunload在微信和部分安卓 WebView 中压根不触发，且 Chrome 已禁用自定义提示文案 -
visibilitychange仅反映标签页可见性，无法区分“切后台”和“真关闭”，iOS 微信中切后台后仍为visible -
onUnmounted（Vue）或componentWillUnmount（React）只响应路由跳转，对关闭 Tab、杀进程、外链跳转完全无感
监听 pagehide 并正确判断 event.persisted
必须检查 event.persisted 值，否则会在每次进入 bfcache 时重复上报，污染数据且浪费资源。只有 event.persisted === false 才代表页面即将彻底卸载——这才是埋点的唯一合法时机。
- 不要写成
window.addEventListener('pagehide', saveExitData)这种无条件调用 - 正确写法：
if (!event.persisted) { navigator.sendBeacon('/log', data); } - Safari 触发
pagehide极其激进（App 切后台就发），建议加一层document.visibilityState === 'hidden'双重确认 - 避免在回调里调用
alert、confirm、window.open—— 全部静默失败
用 navigator.sendBeacon 发送数据的硬性约束
sendBeacon 不是“立刻发出去”，而是交由浏览器后台线程在进程退出前尽力投递。它成功返回 true 仅代表注册成功，不代表已送达；失败则返回 false，需降级处理。
- 只支持同源 URL，且 payload 大小建议控制在 64KB 以内（iOS Safari 实测上限约 32KB）
- 数据类型只能是
Blob、ArrayBuffer、TypedArray、USVString或FormData；不要传对象字面量 - 不要依赖响应：服务器不能做重定向、不能设超时、不能要求鉴权头（CORS 不适用）
- 旧浏览器兜底方案：创建
new Image().src = '/log?data=xxx'，但仅限 GET 且有长度限制
与 freeze 事件协同防漏报
iOS Safari 和新版 Chrome 会先触发 freeze（JS 执行暂停），再发 pagehide。如果只监听后者，某些极端场景（如快速双击 Home 键）可能导致 pagehide 来不及执行就被冻结。
- 务必同时监听：
window.addEventListener('freeze', () => saveState()) - 在
pagehide回调中加守卫：if (!frozen && !event.persisted) saveState() -
freeze触发后 JS 立即暂停，所以所有保存逻辑必须是同步的（不能含await、Promise.then） - 不要在
freeze中尝试 DOM 操作或读取localStorage—— iOS 下可能已不可访问
真正难的不是监听哪个事件，而是在 JS 执行环境随时可能被冻结、中断、清空的前提下，把状态序列化、压缩、校验、提交这一整条链路压进毫秒级窗口。多数漏报不是代码没写，而是写在了错误的执行时机或用了被浏览器策略拦截的 API。
