next()是唯一真正的“放行”操作，允许导航继续执行；next('/')则中断当前导航并发起全新跳转，触发完整守卫流程。
next('/') 和 next() 的本质区别在于：前者是中断当前导航、发起一次全新跳转；后者才是真正的“放行”，让当前导航流程继续执行下去。这个差异看似微小，却直接决定路由是否白屏、守卫是否重复触发、动态路由能否正确加载。
next() 是唯一真正的“放行”操作
它表示当前守卫钩子执行完毕，允许导航管道进入下一个钩子（比如组件内守卫或 beforeResolve）。当所有守卫都调用 next() 且无重定向时，目标路由才会被确认并渲染。此时 URL 变更、组件挂载、afterEach 触发，整个流程自然完成。
- 不带参数的 next() 是守卫中唯一不中断当前导航的行为
- 即使在 beforeEach 中多次调用 next()，也只以第一次为准，后续调用会被忽略（Vue 会警告）
- 若遗漏 next()，导航将永久挂起，页面卡住，控制台报错 “Uncaught Error: next is not called in hook”
next('/') 是一次“中断+新导航”动作
它不会让当前 to 路由继续执行，而是立刻终止本次导航，并以 '/' 为新目标，重新走一遍完整的路由守卫流程——包括再次触发 beforeEach、beforeResolve、组件守卫等。这相当于嵌套了一层新的导航，原 to 被丢弃。
- 执行 next('/') 后，原 to.path 不再生效，新的 to.path 变为 '/'
- router.afterEach 仅对最终确认的导航触发一次，不会为中间中断的导航执行
- 如果新目标路由本身也触发了 next('/')，就可能形成无限循环（例如守卫里无条件写 next('/')）
递归跳转的典型陷阱与真实场景
所谓“递归跳转”，不是指 next(to) 自动递归，而是开发者误以为 next(to) 是“修正后放行”，实则它触发了新一轮守卫，若逻辑未兜底，就会反复进入同一守卫，造成死循环或白屏。
- 动态添加路由后立即访问：addRoutes() 后马上跳转新路由，但新路由尚未注册完成，守卫中判断失败又 next('/login')，登录页再 next(to)，但 to 仍不可达 → 建议改用 next({ ...to, replace: true }) 避免历史堆栈干扰
- 权限校验中误用 next(to)：比如守卫检查用户无权限访问 /admin，于是 next('/403')，但 /403 页面的路由配置缺失或异步组件加载失败 → 导致白屏而非显示错误页
- 守卫中未区分首次访问和重定向后的访问：next('/login') 后，/login 守卫又执行相同逻辑，再次 next('/login') → 浏览器地址栏疯狂闪烁，控制台报 “Maximum call stack size exceeded”
安全使用 next 的关键原则
避免靠猜测，而要明确每次 next 调用的语义：是在放行？还是在重定向？或是中止？
- 需要放行就只用 next()，别加任何参数
- 需要跳转就用 next('/path') 或 next({ name: 'X' })，并确保目标路由已存在、可访问
- 动态路由场景下，优先用 next({ ...to, replace: true }) 替代 next(to)，防止浏览器后退回到一个无效状态
- 所有重定向逻辑前，建议加 guard 条件，例如 if (to.meta.requiresAuth && !isLogin()) { next('/login') }，避免无条件跳转
