表单填到一半用户手滑按了 F5页面白屏半小时的输入没了——这类投诉我接过不止五次。每次复盘都绕不开同一个东西onbeforeunload事件。围绕浏览器刷新、后退、关闭这三个动作做拦截是前端里少数看起来三行代码能搞定、实际到处是坑的活儿。浏览器给的能力边界很窄各家实现还不一样再加上现代 SPA 的路由接管了历史栈原生事件经常不按预期触发。这篇就按我实际做过的几个项目经验把 onbeforeunload 能做什么、不能做什么、怎么组合其他 API 兜底数据、Vue 和 React 里怎么落地、以及我踩过的那些坑一条条讲清楚。适合三类人看正在做表单暂存提醒的前端接手别人遗留代码发现弹窗不生效的维护者还有想搞清楚浏览器到底能不能真的禁用后退按钮这个老问题的同学。看完你至少能判断出哪些需求能做哪些只能换思路绕过。1. 先把 onbeforeunload 的能力边界摸清楚1.1 它到底拦得住哪几种操作onbeforeunload 的触发时机是页面即将卸载但还没卸载。落在实际动作上大概这几类会触发它点击浏览器刷新按钮、按 F5 或 CtrlR、地址栏回车重新导航直接关闭标签页或整个窗口点击页面内的链接跳转到别的地址、调用location.href xxx、表单提交导致导航浏览器前进/后退按钮这个要单独说见后面而下面这些情况不会触发页面加载后用户还没跟页面有过任何交互没点过、没滚过、没输入过、页面因为崩溃被系统回收、以及你用window.open打开的窗口自己关掉的时候。这里有个关键前提容易被忽略现代浏览器要求页面拿到用户激活状态user activation之后才允许弹确认框。翻译一下就是用户从打开页面到触发关闭中间必须至少点过一次、敲过一次键盘或者滚动过。如果用户打开页面一动不动就按了 F5浏览器会直接放行你的弹窗代码等于没写。这个设计是为了防止垃圾站用弹窗堵住用户早年那种确定要离开本站吗的无赖弹窗就是这么被治住的。我做的一个后台系统就吃过这个亏测试同学打开详情页立刻刷新说弹窗没出来。查了半天才发现他没在页面上做任何操作。所以你在自测的时候记得先点一下页面任意位置再刷新。1.2 自定义文案为什么消失了2016 年之前event.returnValue 你的改动还没保存这种写法确实能显示自己的文案。之后 Chrome 51、Firefox 44、Safari 9.1 相继关闭了这个口子现在所有主流浏览器都只显示一段固定的、由浏览器自己决定的提示语大致意思是系统可能不会保存您所做的更改。这个改动的理由很实在早期钓鱼站会把弹窗文案伪造成点击确定继续下载之类的诱导信息用户根本分不清是网页说的还是浏览器说的。收归浏览器统一措辞之后用户至少能确认这是浏览器在拦我。所以别再花时间研究怎么改文案了改不了。你能控制的只有一件事要不要弹。要弹就设置 returnValue 或 return 一个非空值不弹就什么都不做。我在评审代码的时候见过有人为了美化提示引入一堆自定义 Modal那是白费劲——原生确认框出现的那一刻JS 主线程已经被浏览器接管了你的 Modal 根本来不及渲染。注意returnValue必须是非空字符串才会触发弹窗。写event.returnValue 或者false在某些浏览器里不生效统一用return 或者一个非空字符串最稳。1.3 一个最小的可用骨架抛开所有封装最朴素的写法长这样window.addEventListener(beforeunload, function (e) { // 只有存在未保存内容时才拦截 if (!hasUnsavedChanges()) return; e.preventDefault(); e.returnValue ; // 非空即可文案由浏览器决定 return ; });e.preventDefault()和e.returnValue同时写是为了兼顾不同内核的历史行为标准推荐写法是都写上各家浏览器自己会挑认识的那个用。return语句是给极早期 Safari 兜底的现在的 Safari 其实也用 returnValue但留着不亏成本就是一行代码。这里有个设计细节值得说一下hasUnsavedChanges()这个判断必须放在事件回调里实时求值不能在注册事件的时候就确定。原因是用户可能先改了表单又撤销回来状态是动态的。我见过有人写成if (isDirty) addEventListener(...)结果 isDirty 变了之后事件还挂在那里用户明明没改也弹窗体验很糟。2. 刷新、后退、关闭这三个动作能分开处理吗2.1 为什么你分不清用户按的是哪个直接说结论在 onbeforeunload 里你无法可靠地区分刷新、关闭、跳转这三件事。事件对象里没有 type 字段告诉你来源performance.navigation.type只能告诉你当前页面是怎么来的不能告诉你它要怎么走。那为什么还有人在用event.currentTarget.performance.navigation.type 1做判断因为那是判断当前页是不是被刷新的不是判断即将刷新的。真要在卸载前判断动作类型唯一有点用的技巧是监听键盘事件如果用户按的是 F5 或 CtrlR你能在自己的 keydown 里记一个标记。但用户点浏览器的刷新按钮、或者用菜单里的刷新你根本收不到信号。我的建议是别在这上面较劲。业务上真正有价值的区分只有一个用户是不是真的要丢掉数据。至于他是刷新还是关闭对业务决策影响不大——反正数据都可能丢。真要做差异化处理正确的位置在 SPA 路由层不在原生事件层。2.2 后退按钮到底能不能禁用ie 浏览器后退按钮禁用是个搜了很多年的老问题答案很直接不能禁用只能拦截或引导。浏览器把前进后退当成用户的基本导航权利任何网页都无权剥夺。能做的有几件事。第一件是往历史栈里塞记录让后退按钮第一次点下去回到你塞的这条记录上history.pushState(null, , location.href); window.addEventListener(popstate, function () { // 用户点了后退这里会被触发 if (hasUnsavedChanges()) { const ok confirm(有未保存的内容确定要离开吗); if (!ok) { history.pushState(null, , location.href); // 再塞回去 return; } } history.back(); // 用户确认了真退 });这段代码逻辑上能跑但体验很别扭用户点一次后退地址栏闪一下又回来了得再点一次才走。而且如果用户连点后退popstate 会连续触发处理不当会把历史栈搅乱。我在实际项目里只在极少数强需求场景用过这个方案比如在线考试的答题页其他时候宁愿用别的办法。第二件更温和的事是别拦改为自动保存。用户想退就让他退数据在后台悄悄存草稿下次进来恢复。这个思路比硬拦好一百倍后面第 4 节会展开。2.3 SPA 里的后退必须交给路由层传统多页应用里点后退是真的在换文档onbeforeunload 能感知到。但 SPA 里路由切换是history.pushState加组件替换页面根本没有卸载onbeforeunload 压根不触发。这就是为什么很多人抱怨Vue 项目里刷新有弹窗、点路由返回没有。解决办法是把拦截逻辑挪到路由守卫里。Vue Router 提供onBeforeRouteLeaveReact Router 提供useBlockerv6.4 之后或自己监听 popstate。路由层的拦截好处是能精确控制哪个路由需要拦、拦的时候显示什么 UI、用户确认后跳哪里全都是你说了算。要注意路由拦截和原生拦截得配合使用不能只留一个。路由守卫管页面内跳转原生事件管关标签页和刷新。两者判断的脏数据状态要共用同一个 store否则会出现路由层认为脏、原生层认为不脏的分裂情况。我一般把这状态放在 Pinia 或 Redux 里两处都读同一个字段。3. 把拦截逻辑封装成能复用的模块3.1 为什么值得封装裸写 addEventListener 有几个问题多个组件都要用时容易重复注册、组件卸载时忘记 removeEventListener 会泄漏、脏数据判断逻辑散落各处不好维护。我一般会封装成一个离开守卫模块对外暴露 enable、disable、setDirty 三个方法。// leaveGuard.js let dirty false; let listener null; function handler(e) { if (!dirty) return; e.preventDefault(); e.returnValue ; return ; } export default { setDirty(val) { dirty !!val; if (dirty !listener) { listener handler; window.addEventListener(beforeunload, listener); } else if (!dirty listener) { window.removeEventListener(beforeunload, listener); listener null; } }, isDirty() { return dirty; }, };这个设计的关键点是事件监听是跟着脏状态动态挂载和卸载的。页面干净的时候监听器根本不在浏览器完全不会弹窗一旦有改动就挂上保存成功后立刻摘掉。比常驻监听再在回调里判断要干净得多也避免了事件还在但状态已清之类的边界问题。3.2 和表单状态绑定的正确姿势脏状态的来源通常是表单。Vue 里可以 watch 表单对象做深比较React 里可以在 onChange 里打标记。但直接深监听大表单会有性能问题我一般用两种简化策略。一种是首次快照对比进入页面时把表单初始值 JSON 序列化存一份之后每次变更时和快照比。缺点是大对象序列化开销大小表单无所谓。另一种更轻是变更计数任何字段发生值变化就dirty true保存成功时重置为 false。不判断有没有改回来因为用户改回来又改回去的意图很难猜宁可多弹一次也不要漏掉数据丢失。// Vue 3 组合式 API 示例 import { watch, ref } from vue; import leaveGuard from ./leaveGuard; const form ref({ name: , desc: }); watch(form, () { leaveGuard.setDirty(true); }, { deep: true }); async function save() { await api.save(form.value); leaveGuard.setDirty(false); }注意save()里必须在请求成功之后再setDirty(false)。如果放在请求之前保存失败了但用户以为成功了刷新就会丢数据。这个顺序错误我见过不止一次。3.3 移动端和 iframe 的特殊处理桌面端 onbeforeunload 大体能用移动端就完全不同了。iOS Safari 和大部分国产浏览器在移动端基本不显示 beforeunload 弹窗用户从后台划掉应用或者切到别的 App你收不到任何确认机会。安卓 Chrome 稍微好一点但也越来越保守。移动端能依靠的是visibilitychange事件当页面进入后台时触发hidden切回来时触发visible。这个事件不能拦截但可以用来抢救数据——在页面隐藏的瞬间把草稿写进 localStorage 或者发个上报请求。用户后续回来页面从草稿恢复数据不丢。这就是移动端替代 beforeunload 的主流做法。iframe 场景更麻烦。如果页面被嵌在 iframe 里beforeunload是挂在内层 window 上的外层页面的关闭动作能不能触发它取决于两个页面是不是同源、以及外层有没有做处理。我遇到过一个需求是内嵌页面在有未保存内容时点外层关闭按钮要提示最后走的是 postMessage内层监听变化把脏状态推给外层外层拿到状态再决定要不要弹自己的确认。纯靠内层的事件外层是感知不到的。提示iframe 里注册 beforeunload 时要用window.addEventListener而不是document也不要用外层 window 的引用否则跨域下直接报错。4. 拦不住的时候怎么把数据保住4.1 别把希望全押在弹窗上弹窗这种交互用户能关掉、能忽略、能取消。我做过一个统计在一个日活几万的后台系统里大约有三成的刷新行为根本没触发弹窗用户没交互就刷新、移动端、浏览器策略拦截剩下七成里还有一部分用户点了离开。所以弹窗是提醒不是保障。真正保障数据的是自动暂存。核心思路是用户改了什么就记什么不依赖用户确认也不依赖浏览器给机会。存储位置首选 localStorage因为同步、容量够一般 5MB、卸载前也能写。4.2 草稿自动存档的节奏怎么定每次输入都写 localStorage 肯定不行输入密集的时候会造成卡顿。我在项目里用的是防抖加定时兜底的组合输入停止 800ms 后写一次覆盖大部分连续输入场景每隔 10 秒无条件写一次防止用户一直在敲键盘导致防抖永远不触发beforeunload 和 visibilitychange 里各写一次做最后兜底const KEY draft:order-form; let timer null; function flushDraft(data) { try { localStorage.setItem(KEY, JSON.stringify({ data, ts: Date.now(), })); } catch (e) { // 存储满了或者被禁用静默失败 } } function onInput(data) { clearTimeout(timer); timer setTimeout(() flushDraft(data), 800); } // 定时兜底 setInterval(() flushDraft(getCurrentForm()), 10000); // 页面隐藏或卸载时再写一次 document.addEventListener(visibilitychange, () { if (document.visibilityState hidden) flushDraft(getCurrentForm()); }); window.addEventListener(beforeunload, () flushDraft(getCurrentForm()));localStorage 的同步写入在 beforeunload 里是安全的这也是它比 localStorage 之外的方案靠谱的地方——异步的 IndexedDB 很可能还没写完页面就没了。4.3 用 sendBeacon 抢救服务端数据如果是需要上报到服务端的场景navigator.sendBeacon是专门为这个设计的。它发的是 POST 请求浏览器保证在页面卸载后仍然把它送出去不会因为页面关闭而被中断。window.addEventListener(visibilitychange, () { if (document.visibilityState ! hidden) return; const payload new Blob( [JSON.stringify({ event: leave, data: getStats() })], { type: application/json } ); navigator.sendBeacon(/api/track, payload); });sendBeacon 的限制是不能自定义请求头Content-Type 只能用 Blob 的类型、不能读响应、体积一般限制在 64KB 以内。适合做埋点和简单状态上报不适合传大表单数据。如果必须带自定义头可以用fetch的 keepalive 选项fetch(/api/save, { method: POST, headers: { Content-Type: application/json, X-Token: token }, body: JSON.stringify(data), keepalive: true, // 关键允许请求在页面卸载后继续 });keepalive 也有 64KB 的请求体限制两个方案半斤八两选哪个看你的服务端能不能接受自定义头。4.4 visibilitychange 和 pagehide 怎么选这三个事件的可靠度排序我个人经验是visibilitychange 最可靠pagehide 次之unload 最差。原因是现代浏览器引入了往返缓存bfcache页面被放进缓存时unload事件不触发beforeunload也可能被跳过而pagehide和pageshow是专门为 bfcache 设计的配合event.persisted属性还能判断是不是从缓存恢复的。visibilitychange更早触发在页面真正卸载之前就能拿到通知给异步操作留的时间更多。我现在的标准组合是visibilitychange负责数据暂存和上报beforeunload负责弹窗提醒用户pagehide作为移动端和 bfcache 的补充。三个一起上覆盖面最广。unload我已经不挂了Safari 从 14 开始就明确表示不推荐使用它很多场景下它干脆不触发。5. 框架里的落地细节和那些坑5.1 Vue 项目里的组合写法Vue Router 4 提供onBeforeRouteLeave可以在组件内直接注册离开守卫import { onBeforeRouteLeave } from vue-router; import leaveGuard from ./leaveGuard; onBeforeRouteLeave((to, from, next) { if (!leaveGuard.isDirty()) return next(); const ok window.confirm(有未保存的内容确定离开吗); if (ok) { leaveGuard.setDirty(false); // 用户确认放弃清掉状态 next(); } else { next(false); // 阻断导航 } });这里有个坑next(false)阻断导航后浏览器地址栏在某些情况下已经被改了如果用的是 history 模式且用户点了浏览器后退会出现地址和内容不一致。处理办法是在阻断后做一次history.pushState把地址推回去。另一个坑是onBeforeRouteLeave只在组件被路由离开时触发用户直接关标签页它是不会触发的所以第 1 节的原生事件监听不能省。5.2 React 项目里的两种做法React Router v6.4 之前没有官方的路由拦截 API社区方案主要是自己监听 popstate 配合history.block。v6.4 之后有了useBlockerimport { useBlocker } from react-router-dom; function OrderForm() { const blocker useBlocker(({ currentLocation, nextLocation }) { return isDirty currentLocation.pathname ! nextLocation.pathname; }); useEffect(() { if (blocker.state blocked) { const ok window.confirm(有未保存的内容确定离开吗); if (ok) blocker.proceed(); else blocker.reset(); } }, [blocker]); }useBlocker的回调必须返回布尔值别在里面做副作用。另外它的拦截范围只覆盖 React Router 管的历史记录用户手动改地址栏、或者点浏览器刷新还是得靠 beforeunload。两套机制必须同时存在只挂一个肯定有漏网。原生事件在 React 里要用useEffect注册并且在清理函数里移除useEffect(() { const handler (e) { if (!isDirty) return; e.preventDefault(); e.returnValue ; return ; }; window.addEventListener(beforeunload, handler); return () window.removeEventListener(beforeunload, handler); }, [isDirty]); // 依赖 isDirty 变化时重新挂载依赖数组里写isDirty会导致每次变化都重新注册一次事件虽然能用但有性能损耗。更优的写法是 handler 里读取 ref 里的最新值依赖数组保持空数组。5.3 那些真正浪费时间的问题浏览器策略会随版本变化同一个写法三个月前有效更新后可能就不行了。我在几个主流浏览器上做过对比测试整理成下表方便你快速定位问题。现象可能原因处理方式弹窗完全不出现用户尚未与页面交互未获得 user activation引导用户先操作页面或接受这个限制弹窗文案是浏览器默认的现代浏览器已停止支持自定义文案无法修改改为在页面内做额外提示刷新有弹窗路由返回没有SPA 路由切换不触发原生事件补路由守卫拦截移动端从不弹窗移动浏览器普遍不支持改用 visibilitychange 做自动暂存事件回调里设置状态无效事件触发时主线程已被接管所有状态操作必须提前完成只在首次刷新弹一次监听器被意外移除或状态被重置检查 removeEventListener 调用位置开发环境正常生产环境不弹打包工具对代码做了压缩优化检查事件绑定是否被摇树移除iframe 内不触发事件挂在了错误的 window 上用 iframe 自身的 window 注册最后两行是我踩得最深的。生产环境弹窗消失的那次排查了一下午最后发现是构建工具把看似没有副作用的事件注册语句当成死代码删掉了加了一行 console 保住了它。这个教训让我养成了一个习惯所有事件注册都封装在带副作用的函数里别在模块顶层裸写。6. 排查思路和常见问题速查遇到弹窗不生效我一般按这个顺序查能覆盖九成问题。第一步查事件有没有挂上。在控制台执行getEventListeners(window).beforeunloadChrome 专有看有没有 listener。没有就是注册代码没跑到或者被构建工具干掉了。第二步查 user activation。打开一个全新标签页不点任何东西直接刷新本来就不该弹。这不需要修是预期行为。第三步查脏状态。在 handler 第一行打日志看这个函数到底有没有被调用、调用时 dirty 是不是 true。很多问题其实不是事件没触发而是脏状态判断有误。第四步查框架层。如果是 SPA用路由守卫拦截的部分和原生事件拦截的部分要分开测。手动改地址栏测原生点页面内的链接测路由别混着测。第五步查浏览器差异。Chrome 能用不代表 Safari 能用Safari 对 beforeunload 的处理一向保守实测下来经常需要配合 pagehide 才有完整覆盖。关于检测到开发者工具已打开请关闭后刷新页面继续访问这类需求我得说一句这是很多在线考试和答题系统会提的需求但纯前端做不到可靠检测。能用的只有窗口尺寸突变这种脆弱方案用户把开发者工具停靠在独立窗口就失效了。真要防作弊必须在服务端做行为分析和数据校验前端的任何检测都只是提高门槛不是保障。还有一个经常被问到的js 能区分浏览器是关闭还是刷新吗前面说过原生事件区分不了但有个间接办法页面加载时在 sessionStorage 里写一个标记卸载时读它。如果是刷新sessionStorage 会保留同标签页如果是关闭标签页再重开sessionStorage 被清空。这个方法能区分同一标签页的刷新和标签页被关掉重开但依然区分不了刷新和跳转到站内其他页面因为这两种都保留 sessionStorage。用在业务上要谨慎别把不确定的判断当确定结论。我个人最推荐的做法是把 onbeforeunload 当成体验优化而不是数据保障。它的价值在于给用户一个你确定吗的犹豫机会仅此而已。真正把数据保住的是轻量级的自动暂存加服务端持久化。7. 写在最后的一点个人体会做了这么多年表单和编辑器我对这个事件的看法一直在变。早期我会花大量时间研究怎么把拦截做得滴水不漏怎么在用户每次刷新时都弹窗甚至想过用各种 hack 提高弹窗率。后来发现这套思路的方向就错了——用户刷新页面往往是有原因的可能是页面卡了、可能是想重新加载、也可能是想放弃这次操作。硬拦只会让人烦躁。现在我的默认策略是数据随时存弹窗只在真正危险的场景出现。比如订单已填但未提交、编辑器内容超过一定长度、上传任务进行中。这些场景弹一次是必要的其他时候就静静放行。什么时候该弹、什么时候不该弹这个判断比任何技术实现都重要。还有一个细节值得分享如果你在做的是内部后台系统用户群体固定、容忍度较高beforeunload 的效果会好很多如果是面向 C 端的页面尤其移动端就别指望它了老老实实做草稿箱和自动恢复。我见过太多项目把交互设计的责任推给一个事件最后被用户投诉淹没。技术方案要跟着用户场景走不是反过来。