Navigation API 仅提供导航观察能力，无法拦截或阻止导航；beforenavigate 事件禁止 abort、重定向或同步权限校验，因浏览器已启动资源预加载，且执行时机晚于导航发起，无法替代路由守卫。
Navigation API 不能用来拦截或阻止导航，beforenavigate 和 navigate 事件都禁止调用 event.preventDefault()；它只提供观察能力，不是控制接口。
为什么 beforenavigate 无法替代路由守卫
规范明确禁止在 beforenavigate 中 abort、重定向或同步校验权限。此时浏览器已开始 DNS 查询、TLS 握手，甚至预加载目标资源——你只能读取 event.destination.url，不能修改或取消。
- 用户点击链接后，
location.href还没变，但后退/前进意图已不可逆 - 权限判断（如登录态）必须在导航发起前完成，而
beforenavigate是异步事件，执行时机无法保证早于 DOM 更新 - 没有等价于
next('/login')的 API；强行跳转需手动调用location.assign()，会额外插入一条 history 记录，导致后退栈错乱
navigate 事件适合做哪些轻量增强
navigate 在 DOM 更新完成后触发，适合“事后归因”和体验标记，而非流程控制。
- 通过
event.navigationType区分是push、replace、back、forward还是reload，记录用户来源路径 - 结合
document.visibilityState === 'visible'打点真实首屏渲染时间，比DOMContentLoaded更贴近用户感知 - 在 SPA 切换后恢复滚动位置：必须等
navigate回调执行完毕再调用window.scrollTo()，否则可能被浏览器原生滚动恢复逻辑覆盖
常见误用与边界限制
Navigation API 的作用域严格限定在当前 document，不跨 tab、iframe 或 Shadow DOM 共享状态。
立即学习“前端免费学习笔记（深入）”；
- 微前端子应用各自调用
pushState，主框架无法通过 Navigation API 感知——它不监听 History API 变更 - 想同步登录态？仍得靠
localStorage+storage事件，或BroadcastChannel - 给
<a></a>标签加onclick="navigate()"会绕过navigate事件；所有内部链接必须用原生 href 才能触发
真正关键的不是“怎么拦截”，而是“在哪一环介入最安全”——Navigation API 的设计定位是信号增强层，不是流程控制层。把它当监控探针用，别当守门员用。
