有没有过这种情况？你正熬夜改方案写到一半 手滑点了浏览器右上角的× 刚想骂娘 “我还没保存呢！” 就弹出个灰溜溜的确认框—— “确定要离开此页面吗？未保存的内容将丢失”

哈哈我猜90%的互联网打工人dou遇到过 今天咱就不端着了 以老友唠嗑的方式 拆穿前端圈里 “用户到底有没有真关页面” 的那些弯弯绕绕

先别急着翻代码 咱们先聊个扎心事实： 你以为Neng拦住用户关页的 “确认框” 其实早过时了 甚至在某些浏览器里 它就是个 “聋子耳朵——摆设”

提起拦截用户关页 第一个跳进脑子里的肯定是 beforeunload 没错它就是前端圈里Zui老牌 的 “离页拦截器”

早年ZuoPC端项目时 这玩意简直是 “神器”：

贴段代码就搞定——只要用户触发关闭/刷新/跳转 浏览器必弹提示框 想走？先留句话

但害…时代变了啊朋友 现在移动端占比快80%了 你猜怎么着？ iOS Safari直接把 beforeunload 的自定义文案阉了 不管你写啥 返回值只会变成系统默认的 “此网页试图阻止你离开…” geng过分的是 Android某些浏览器直接屏蔽了这个事件触发权限

我之前Zuo电商项目就踩过坑： H5支付页用 beforeunload 拦未完成支付 用户反馈说 “关不掉页面！要点两次叉！” 后来查文档才知道——苹果爸爸为了 “保护隐私和流畅度” 早把这口子卡得死死的

别急 beforeunload 的兄弟 unload 是不是geng香？ 理论上 unload 在页面彻底卸载前触发 适合ZuoZui后一步的数据清理

但哥俩名字像亲兄弟 命运却天差地别——

这段代码kan着没问题吧？实则埋了颗雷： 现代浏览器为了追求加载速度 unload事件里执行异步操作大概率会被中断

数据统计过 iOS Safari上 unload触发率不足30%！ 也就是说你吭哧吭哧写的数据上报代码 十次有七次白搭

我上家公司的数据分析师吐槽过： “明明埋点逻辑没错 为什么留存率统计总是差那么一点？哦…原来大部分用户关页时数据根本没传出去…”

说了那么多 “不行” 的方案 该亮出正主啦——pagehide事件搭配navigator.sendBeacon

先别急着记知识点 咱们先聊场景： 假设你Zuo一个视频播放页 用户kan到一半关了页 你想上报 “播放时长/暂停次数/当前进度”这些核心数据咋办？

用 pagehide！它比 unloadgeng贴近 “用户真实离开” 的状态

kankan正确写法：

sendBeacon解决了你Zui头疼的数据丢失问题 它不是立即发送请求而是把请求放进浏览器队列里等空闲时发；就算此时网络断连也会重试直到成功；哪怕网页Yi经关掉进程结束前也会把队列里的数据发完——这叫 “可靠传输机制 ”懂吗朋友！

然后 event.persisted帮你区分两种 “假关闭 ” 什么叫假关闭?就是用户点后退键回到上一页时当前页其实没销毁只是进了 bfcache这种情况下你的视频播放进度其实还在! Ru果用 unload/event你根本分不清到底是真关还是退一步 ——而 pagehide里 event.persisted为true就是告诉程序 : "兄弟这页还在缓存呢别慌删数据!"