Navigation API 仅提供导航观察能力，无法拦截或阻止导航；beforenavigate 事件禁止 preventDefault()，不能替代路由守卫；navigate 事件适合事后归因与体验优化，非流程控制；其作用域限于当前 document，不跨 tab 或 iframe 共享。
Navigation API 不能用来“拦截并阻止”导航，beforenavigate 和 navigate 事件都禁止调用 event.preventDefault()，它只提供观察能力，不是控制接口。想实现类似 Vue Router 的守卫效果，必须保留现有路由库，把 Navigation API 当作信号增强层来用。
为什么 beforenavigate 无法替代 router.beforeEach
规范明确禁止在 beforenavigate 中阻断或重定向导航——浏览器已在解析目标 URL、发起 DNS 查询、建立 TLS 连接，此时你只能读取 event.destination.url，不能 abort、不能修改、不能同步校验权限。
-
beforenavigate触发时，location.href还没变，但资源预加载已开始，用户点击后退/前进的意图已不可逆 - 所有权限判断（如登录态）必须在导航发生前完成，而
beforenavigate是异步事件，无法保证执行时机早于 DOM 更新 - 没有等价于
next('/login')的 API；强行跳转需手动调用location.assign()，这会额外插入一条 history 记录，导致后退栈错乱
哪些场景下可以用 navigate 事件做轻量增强
navigate 在 DOM 更新完成后触发，适合做“事后归因”和“体验标记”，而非流程控制。
- 记录用户从哪个页面跳转而来（
event.navigationType可区分push/replace/reload/back/forward） - 结合
document.visibilityState === 'visible'打点真实首屏渲染时间，比DOMContentLoaded更贴近用户感知 - 在 SPA 切换后自动恢复滚动位置——注意：要等
navigate回调执行完毕再操作window.scrollTo，否则可能被浏览器滚动恢复逻辑覆盖
常见误用：试图用 Navigation API 实现跨 tab 同步或状态共享
window.navigation 是 per-document 实例，每个 tab、iframe、甚至同一页面的 Shadow DOM 中的 navigation 对象完全独立，不共享状态、不通信、不广播。
立即学习“前端免费学习笔记（深入）”；
- 想同步登录态？仍得靠
localStorage+storage事件，或BroadcastChannel - 微前端子应用各自调用
pushState，主框架依然无法感知——Navigation API 同样无能为力，它不监听 History API 的变更 - 不要给
a标签加onclick="navigate(...)"，这会绕过navigate事件；所有内部链接必须用原生<a href="/about">才能触发事件
真正关键的不是“怎么拦截”，而是“在哪一环介入最安全”。目前（2026 年 4 月），Chromium 120+ 支持 beforenavigate，Firefox 和 Safari 仍无明确支持计划。别把它当路由底座，它只是个更准的传感器——用错地方，反而让路由逻辑更脆弱。
