前端跳转拦截与确认弹框实战：beforeunload、路由守卫与Promise封装

1. 跳转弹框到底拦截的是什么：三类跳转与两种拦截层级

先说我最近真实遇到的一个需求。后台管理系统的订单编辑页，运营同事填了十几分钟的表单，临时去开了个会，回来习惯性点了一下左侧菜单的"订单列表"，页面瞬间切走，所有改动全没了。那天下午运营群里炸了锅，第二天这个需求就排到我手里：所有包含未保存数据的页面，跳转之前必须弹框确认。

这个需求听上去一句话就能说清，真正动手做才发现，"跳转"这两个字背后藏着好几种完全不同的情况。我把它们整理成三类，分不清楚这三类，后面写代码就是在碰运气。

第一类是浏览器级跳转。用户手动刷新页面、关闭标签页、在地址栏输入新地址回车、或者点击一个指向外部链接的普通<a>标签导致整页加载。这类跳转一旦发生，当前页面的 JavaScript 执行环境会被直接销毁，不管你的应用是 Vue 还是 React，任何代码都无法在跳转完成后继续执行。你唯一能做的就是"在跳转发生前的那一刻"打断它。

第二类是单页应用内部的路由切换。Vue Router、React Router 管理的页面互跳，比如从编辑页跳到列表页、从详情页跳到首页。这类"跳转"实际上并没有卸载当前文档，只是改了 URL 和视图渲染，JavaScript 运行上下文一直活着。所以路由层的代码完全有机会拦下来，先弹框，等用户确认了再放行。

第三类是 Hash 变化和浏览器前进后退。hash 模式路由下，window.location.hash的改变会触发hashchange事件；history 模式路由下，浏览器工具栏的前进后退按钮会触发popstate事件。这两条路径特别容易被人忽略，但恰恰是手机端用户误触发的重灾区——Android 手机的系统返回手势一划，页面就退了，表单一个字没存。

对应地，拦截手段也分两个层级。第一层是浏览器原生提供的beforeunload事件，它专门对付第一类跳转；第二层是路由库自带的导航守卫或阻塞机制，用来处理第二类和第三类中可控的部分。这两层不能互相替代，一个完整的"跳转前弹框"方案必须两层同时上，否则总会漏掉某个入口。

我承认自己一开始在这个问题上栽过跟头。当时想的是"路由守卫处理内部跳转就够了，浏览器刷新让用户自己负责"，结果上线第二天就有人在编辑页按了 F5，白填半天数据，骂骂咧咧来找我。反过来也一样，如果你只挂了beforeunload，SPA 内部从编辑页切到列表页，页面根本没卸载，这个事件根本不会触发。

所以动手之前，先画清楚你有哪些跳转入口。我的习惯是做一张清单，把"刷新""关闭标签页""内部路由跳转""浏览器返回""点击外链""地址栏输入"全部列出来，然后逐个确认：这个入口由哪一层代码负责拦截？拦不住时的兜底方案是什么？这套清单做完，实现方案基本上就是水到渠成的事了。

还有一个产品层面的问题值得提前想清楚：弹框不是越频繁越好。如果用户只是从列表页跳到详情页，每跳一次都弹框，用户会形成"看到弹框就无脑点确定"的条件反射，真要拦截的时候反而拦不住。弹框只应该出现在"当前状态可能被破坏"的页面——最典型的就是表单有未保存修改、页面有正在进行的上传任务、或者用户正在播放的音频/视频需要停止。判断"是否有未保存修改"这件事，建议用脏标记（dirty flag）机制，而不是每次跳转都无脑弹。

2. beforeunload 原生拦截的能力边界与浏览器政策限制

beforeunload是一个存在了很多年的浏览器 API，几乎所有 JavaScript 开发者都听过，但真正用对它的人不多。原因很简单：这些年浏览器厂商出于反骚扰的考虑，把这个 API 的能力一砍再砍，网上大量旧教程写的用法现在根本不起作用。

标准的挂载方式是这样的：

function beforeUnloadHandler(event) { event.preventDefault(); event.returnValue = ''; } // 有未保存数据时挂载 window.addEventListener('beforeunload', beforeUnloadHandler); // 保存完成或确认离开后移除 window.removeEventListener('beforeunload', beforeUnloadHandler);

早年间的做法是给returnValue塞一段自定义文案，比如"你还有未保存的内容，确定要离开吗？"，浏览器会把这行字显示在原生确认框里。但从 Chrome 51 开始，桌面端不再显示自定义文案，统一使用浏览器内置的默认提示；Chrome 60 之后进一步调整了提示样式。现在你写什么字符串都没用，浏览器只认"你有没有阻止默认行为"这个动作，显示的永远是它自己的话术。

还有一个更隐蔽的限制：从 Chrome 68 开始，如果页面从未发生用户交互（比如用户刚打开页面就直接刷新），beforeunload弹框不会出现。这是浏览器为了防广告页和恶意页面的策略——你不允许网站在用户没有操作的情况下，用弹框骚扰用户。换句话说，这个事件本质上是"用户主动操作离开时，给页面一个挽留的机会"，而不是页面可以随时按住的闸门。

我实际测试过的主流浏览器行为是这样的：

这里要特别强调一个移动端的坑：iOS 上 Safari 的beforeunload支持一直很不稳定。很长一段时间里，iOS Safari 根本不触发这个事件，用户右滑关闭或切换标签页时，页面代码根本得不到执行机会。最近几个版本虽然有所改善，但依然不可控。所以移动端的核心防线绝对不能押在beforeunload上，路由守卫和可控弹框才是主力。

更关键的是，就算beforeunload正常触发，你也没办法弹出自己的 React 组件或 Vue 弹窗——它只能显示浏览器原生的确认框，样式完全不可控，也没有任何业务逻辑的承载空间。而且beforeunload处理器内部的所有操作都必须在同步代码中完成，你不能在里面发异步请求、不能 await 一个 Promise、不能等待用户在一个自定义弹框上点按钮。

所以我的定位是：beforeunload只做最后一道兜底，不做主要交互。它能覆盖的是"用户直接关标签页、刷新页面"这种路由层完全无法感知的场景，代价是体验粗糙、不可定制。真正精细的"跳转前弹框"，必须放在路由层去实现。

一个实操细节：beforeunload监听器的挂载和移除，应该跟着脏标记走。表单每次输入变化时，判断数据是否和初始值一致，不一致才注册监听器，一致就移除。千万不要一进页面就把监听器挂上然后永远不摘，否则用户在页面上什么都没干，点刷新也被浏览器拦住，这种体验很愚蠢。

function updateDirtyState(isDirty) { if (isDirty) { window.addEventListener('beforeunload', beforeUnloadHandler); } else { window.removeEventListener('beforeunload', beforeUnloadHandler); } }

3. 路由层面的真正拦截：Vue Router 守卫与 React Router useBlocker

如果说beforeunload是粗线条的兜底，那路由守卫就是精细控制的真正主角。SPA 内部的所有页面切换，都可以在路由层被拦截、挂起、等待用户决策后再放行。

先看 Vue Router。最常用的方式是在全局前置守卫beforeEach里做判断，发现目标页面需要离开当前表单页且表单是脏的，就挂起导航。注意，不是调用next(false)就完事了——你需要把这次导航的to和next保存下来，弹出自定义弹框，等用户点了"确定"再继续执行next()，点了"取消"就丢弃这次导航。

// store 或组件外部定义一个模块级变量 let pendingNavigation = null; router.beforeEach((to, from, next) => { const formStore = useFormStore(); // 假设你的表单状态在 Pinia 里 const isLeavingFormPage = from.meta.requiresConfirm; const isDirty = formStore.isDirty; if (!isLeavingFormPage || !isDirty) { next(); return; } // 挂起导航，记录待处理对象 pendingNavigation = { to, next }; // 触发自定义弹框显示 confirmDialogStore.open({ title: '离开当前页面？', content: '你有未保存的修改，确定要离开吗？', }); }); // 弹框确认离开 function onConfirmLeave() { if (pendingNavigation) { const { next } = pendingNavigation; pendingNavigation = null; confirmDialogStore.close(); next(); // 放行 } } // 弹框取消离开 function onCancelLeave() { pendingNavigation = null; confirmDialogStore.close(); }

这套模式的核心思路是"挂起导航 + 暂存 next 引用 + 弹框确认后再决定调用还是不调用"。有一个细节必须注意：next只能调用一次，而且不能既调用又丢弃。所以在onConfirmLeave和onCancelLeave里，调用next()之后必须立即把pendingNavigation置空，防止用户连点两次按钮导致next被重复调用。

Vue Router 也支持组件内守卫beforeRouteLeave，它的好处是能直接访问当前组件的this或 setup 里的状态，不需要把表单状态提升到全局 store。但组件内守卫的缺点是逻辑比较分散，如果多个页面都需要拦截，你就要在每个组件里都写一遍。我的习惯是：全局beforeEach处理所有需要确认的页面，组件内beforeRouteLeave只在特殊业务逻辑（比如某个页面离开时需要清理定时器）时用。

React Router 这边的情况略有不同。React Router v6.4 之前，官方没有提供路由阻塞能力，社区要么自己 hacksnavigate函数，要么用第三方库。v6.4 之后，官方正式提供了useBlocker这个 Hook，前提是你必须使用数据路由器（createBrowserRouter），普通的<BrowserRouter>组件模式用不了。

import { useBlocker } from 'react-router-dom'; function EditOrderPage() { const [isDirty, setIsDirty] = useState(false); // 只有跨路由且表单脏时才阻塞 const blocker = useBlocker( ({ currentLocation, nextLocation }) => isDirty && currentLocation.pathname !== nextLocation.pathname ); useEffect(() => { if (blocker.state === 'blocked') { setShowConfirmDialog(true); } }, [blocker]); const handleConfirm = () => { setShowConfirmDialog(false); blocker.proceed(); // 放行 }; const handleCancel = () => { setShowConfirmDialog(false); blocker.reset(); // 取消这次导航 }; return ( <> <OrderForm onDirtyChange={setIsDirty} /> {showConfirmDialog && ( <ConfirmDialog onConfirm={handleConfirm} onCancel={handleCancel} /> )} </> ); }

useBlocker的返回值有三种状态：unblocked（未阻塞）、blocked（已阻塞待决策）、proceeding（正在放行）。你需要监听blocked状态来触发自定义弹框，用户确认后调用blocker.proceed()，取消则调用blocker.reset()。

这里有两个容易踩的坑。第一，useBlocker的函数参数每次渲染都会重新创建，如果你不在内部用依赖状态做判断，可能会导致在无关的路由切换时也触发阻塞。上面的示例代码中，我在函数里判断了路径是否变化，这样从编辑页跳到同一个路径的不同参数就不会误报。第二，useBlocker所在的组件必须是路由组件，否则 Hook 获取不到当前路由信息。

如果把 Vue Router 和 React Router 的拦截方式放到一起对比，逻辑是很相似的：

4. 从零封装一个可复用的"跳转确认弹框"：状态设计与 Promise 模式

路由守卫只是拦截了跳转，真正跟用户直接对话的，是那个确认弹框本身。很多项目直接复用组件库里的Modal.confirm，图省事，但做深了你就会发现，跳转确认弹框和普通消息弹框有一个本质区别：弹框关闭时，必须把"用户的选择"以确定性的方式告诉路由层。

推荐用 Promise 来封装整个流程。路由层那边只要"等待一个 Promise，resolve 就放行，reject 就取消"，而弹框内部负责展示 UI、监听用户点击、最终 resolve 或 reject。这样路由层和弹框层完全解耦，你甚至可以无感替换弹框实现。

下面是一个 Vue 3 + Composition API 的思路，核心是维护一个"待决 Promise"：

// useConfirmLeave.js import { ref } from 'vue'; const isVisible = ref(false); const title = ref(''); const content = ref(''); let resolver = null; function openConfirmLeave(options = {}) { title.value = options.title || '离开当前页面？'; content.value = options.content || '你有未保存的修改，确定要离开吗？'; isVisible.value = true; return new Promise((resolve) => { resolver = resolve; }); } function handleConfirm() { isVisible.value = false; resolver?.(true); resolver = null; } function handleCancel() { isVisible.value = false; resolver?.(false); resolver = null; } export function useConfirmLeave() { return { isVisible, title, content, openConfirmLeave, handleConfirm, handleCancel, }; }

然后在路由守卫里这样配合：

import { useConfirmLeave } from '@/composables/useConfirmLeave'; router.beforeEach(async (to, from, next) => { if (!from.meta.requiresConfirm || !formStore.isDirty) { next(); return; } const confirmed = await openConfirmLeave(); if (confirmed) { next(); } else { // 不调用 next，导航自动取消 } });

Promise 方案的好处是异步控制流非常清晰，路由守卫不再需要手动维护pendingNavigation对象，代码可读性提升了一个档次。坏处是你要小心事件循环的时序：如果用户在弹框出现之前就触发了另一次路由跳转，可能导致 Promise 永远 pending。我通常会在openConfirmLeave里加一个保护——如果上一次弹框还没关闭，就先自动 cancel 上一次。

弹框 UI 本身也有一些交互细节，做得不好会让人觉得很业余：

按钮焦点策略。弹框打开时，默认焦点应该放在"取消"按钮上，而不是"确定"上。想一想原因：用户可能是误触了导航，此时他大概率是在慌乱中想赶快退出，如果默认焦点在"确定"，他随手按一下回车，表单就白填了。默认焦点在"取消"，回车等于反悔，是最安全的选择。

键盘事件处理。Esc键应该等同于点击"取消"，这也是安全方向。如果你不想维护全局键盘监听，可以在弹框组件挂载时监听keydown，卸载时移除监听。

自动聚焦问题。自定义弹框不像浏览器原生 alert 那样自动获得焦点，所以需要手动把焦点移到弹框容器上，同时建议设置aria-modal="true"，让屏幕阅读器知道这是个模态对话框。无障碍这件事很多人不当回事，但我遇到过真实用户是键盘导航使用者，他反馈说弹框出现后 Tab 焦点还在背后的表单里，按 Tab 会莫名奇妙地修改表单值，这个问题定位了很久才发现。

重复拦截问题。用户第一次点"取消"留在当前页，第二次再点导航又弹框，这是正常的。但要注意不要出现"弹框还没关，又弹一个"的情况，所以弹框的显示状态必须全局唯一。我在生产环境踩过一次：一个页面既注册了全局beforeEach拦截，组件内部又写了个beforeRouteLeave同时拦，结果弹了两个框，用户关掉一个还剩一个，彻底蒙了。解决方案是在项目里约定：全局守卫只负责"是否需要拦截"的判断，弹框只渲染一次，组件内不再重复拦截。

5. 多标签页、浏览器返回与草稿恢复：边界情况的实测复盘

主流程跑通之后，真正的考验在边界情况。我把自己在真实项目里踩过的坑一条条列出来，每一条都有对应的解决方案。

浏览器返回按钮。history 模式下，用户点击浏览器返回按钮触发的是popstate事件，这个事件本身无法被取消。也就是说，无论你愿不愿意，浏览器历史栈已经回退了。Vue Router 的方式是在路由守卫里判断：当前页是编辑页且表单脏，beforeEach重新把路由指回编辑页；React Router 的useBlocker对前进后退同样生效，blocker.reset()之后路由会回到原来的状态。但要注意这个过程会产生一条额外的历史记录，用户可能发现按了返回又弹回来，再按一次返回才能真正离开。这是"浏览器历史栈不可撤销"的物理限制，没有完美的解法，只能在体验上做一个权衡——我个人觉得"多一次拦截"比"数据丢失"好得多。

hash 模式下的 hashchange。如果你的应用用的还是老式的 hash 路由，window.location.hash的修改会触发hashchange事件，而这个事件同样无法被阻止。一个绕过方案是：在修改 hash 之前先检查脏标记，如果脏，就把 hash 改回去并弹出确认框。但如果你用的路由库（比如 Vue Router）已经封装了 hash 模式，通常它的内部跳转还是会走路由守卫，不需要你自己处理hashchange。

多标签页的天然限制。用户在两个标签页同时打开同一个编辑页，在标签 A 修改数据，然后切到标签 B 点击导航离开。标签 B 里的表单状态是旧数据，脏标记可能是 false，所以不会弹框，但用户脑子里的"我正在编辑的内容"是标签 A 的最新状态。这个场景目前无解，beforeunload和路由守卫都作用在各自的标签页上下文里。我能给的实操建议是：如果项目对数据一致性要求高，可以考虑用BroadcastChannel或localStorage的storage事件在多个标签页之间同步脏状态。但说实话，为这个场景做的投入产出比很低，我一般建议产品经理接受这个限制。

草稿恢复机制。比起费尽心思想着怎么拦截所有跳转，更符合用户心流的做法是：弹框确认只是第一道防线，真正保险的是把数据自动存到本地。我现在的做法是：表单数据在输入过程中节流写入localStorage，key 按"页面路由 + 记录 ID"来区分；页面加载时如果发现本地有未提交的草稿，先恢复再提示用户"检测到未提交的草稿，是否恢复？"。有了这层兜底，就算弹框没拦住、浏览器崩溃、甚至用户手动杀进程，数据都不会丢。弹框防的是"误操作"，草稿恢复防的是"任何意外"，两者是互补关系。

异步保存的竞态。一个容易被忽略的时序问题：用户点击"确认离开"，弹框关闭，此时页面可能正在执行表单数据的异步提交。如果异步提交还没返回，页面已经切换到下一个路由，组件被销毁，异步回调里的setState就会在已卸载组件上执行，轻则抛警告，重则内存泄漏。我的解决办法是：确认离开之前，先 await 一次表单保存——如果保存失败，弹框显示"保存失败，是否仍然离开？"，并提供重试按钮。这样把离开动作和保存动作做成一个原子操作，彻底杜绝竞态。

async function handleConfirm() { confirmLoading.value = true; try { await formStore.saveDraft(); // 保存成功才真正放行 isVisible.value = false; resolver?.(true); resolver = null; } catch (e) { saveFailed.value = true; } finally { confirmLoading.value = false; } }

弹框按钮的连点防抖。用户快速双击"确认"按钮，按钮的 click 事件会触发两次，导致resolver(true)被调用两次。虽然第二次调用时resolver已经被置空，但最好在handleConfirm里加防抖或者用一个isHandling标记，防止在异步保存逻辑里出现重复请求。

只有 hash 变化的监听。有些页面里，用户点击一个按钮只是为了改变查询参数（比如列表页的分页），并不是真的想离开当前页。如果你的useBlocker回调只比较路径而忽略了查询参数的变化，就会导致换个分页也弹框，体验非常割裂。我建议拦截条件严格一点：只比较pathname，忽略 search 和 hash 的变化，除非你的业务明确要求在修改查询参数时也做确认。

6. 兼容性矩阵、测试清单与我的落地经验

方案写完了，不实测等于没写。我的测试清单和踩坑记录，一次性分享出来。

先看兼容性。这里说的是我在真实项目里验证过的行为，测试时间大概是近两年的主流版本，但浏览器迭代很快，建议你上线前用自己的测试机再跑一遍：

测试用例清单我建议按这样的思路组织：

• 表单从未修改：点击导航，不弹框，直接跳转。
• 表单有修改：点击导航，弹框，点"取消"留在原页，表单数据完整。
• 表单有修改：点击导航，弹框，点"确定"跳转成功。
• 表单有修改：点浏览器返回，弹框（或重定向回原页），数据不丢。
• 表单有修改：刷新页面，浏览器原生确认框出现，取消刷新后数据仍在。
• 表单有修改：关闭标签页，原生确认框出现。
• 弹框打开状态下按 Esc：弹框关闭，停留在原页。
• 弹框打开状态下回车：默认焦点在"取消"，停留原页。
• 快速双击确认按钮：只产生一次保存请求。
• 确认离开且保存失败：弹框升级为报错状态，提供重试。

这个清单不是一次性写完就完事了，每次改了弹框组件或者路由配置都应该把主流程过一遍。我个人的习惯是把它写成一个 Playwright 的自动化测试脚本，跑在 CI 里，几秒钟出结果，比人肉点十遍靠谱得多。

再分享几个我在实际项目中得出的产品层面结论。

弹框文案极其重要。一开始我写的是"你确定要离开吗？"，用户根本不知道自己为什么要被问这一句。后来改成"你有 3 项修改尚未保存，离开页面后这些修改将丢失"，用户一眼就明白利弊，误操作率立刻下降。要点是：说清楚"离开会失去什么"，而不是干巴巴地问"是否确定"。

不要对同一用户在同一页面反复弹框。用户第一次选择"取消"留下来了，可能是在权衡要不要保存；第二次又选择"取消"；第三次你再弹，他可能已经不耐烦了。有的团队会给弹框加一个"记住我的选择"复选框，但我实测下来，这个复选框的价值不大，用户不知道这个"记住"会持续多久，反而会增加认知负担。更合理的做法是：把"取消"设计成常态，同时提供明显的"保存并离开"按钮，把选择权交还给用户。

弹框不要做成浏览器默认样式的"加深版"。展示层次上，弹框应该清晰地区分两个动作：一个是"安全退出"（放弃修改），一个是"保存后离开"。如果两个按钮的视觉权重一样，用户分不清哪个更安全。我的设计习惯是：主要推荐按钮是"保存并离开"，次要按钮是"仍然离开"，两个按钮颜色和边框有明显区分。这样即使用户懒得思考，默认也会走数据不丢失的路。

配置化比硬编码好。几个月后产品经理大概率会要求"订单页弹框、客户页不弹""草稿箱不弹但正式提交要弹"。所以弹框的触发条件千万别硬编码在组件里，我用的是路由 meta 配置 + store 里的脏标记判断，两两组合，改需求只动配置不动代码：

// 路由配置 { path: '/order/edit/:id', component: OrderEdit, meta: { requiresConfirm: true, confirmMessage: '你有未保存的订单修改，离开后将丢失。', }, }

还有一个容易被忽略的细节：用户从编辑页进入了一个新的编辑页，如果两个页面都是requiresConfirm，弹框逻辑要能处理"从脏页面到另一个也会变成脏的页面"的情况。我的策略是：进入新页面时先把上个页面的脏状态清零再渲染，避免连锁弹框。

最后说一个我在实测中得到的意外发现。一开始我把弹框做得非常"完善"，又是标题又是正文，还有一个警示图标，按钮文字也排得很讲究。结果 A/B 测试下来，"完善版"弹框的取消率反而比简洁版低。分析了一下原因：用户看到的是一个复杂弹框时，倾向于不仔细阅读直接点最显眼的按钮快速离开；而一个只有一句话和两个按钮的轻量弹框，用户反而会花 0.5 秒读一下内容再决定。弹框的设计目标不是让用户多停留，而是让用户在下意识操作之前多一个"思考停顿"。这个停顿不需要太长——人眼读一句话 300 到 500 毫秒就够了，剩下的交给按钮布局去引导。

如果你也在做类似的需求，我最大的建议是：别一上来就动手写弹框组件，先把跳转入口梳理干净，再用 Promise 把路由守卫和弹框解耦，最后用自动化测试把关键路径锁住。这套思路跑顺之后，你会发现"跳转前弹框"这个看似小到不值一提的需求，实际上是把前端路由、浏览器事件、状态管理、异步时序串起来的综合题，做完之后你对整个应用的导航架构都会有更深的理解。