Navigation API 怎么拦截单页应用导航

单页应用最容易失控的地方不是组件渲染，而是导航入口：链接点击、浏览器后退前进、脚本调用和表单提交可能走不同路径。Navigation API 提供了统一的 navigate 事件，适合把“判断 URL、加载数据、更新视图”收拢到一个路由边界里。

Navigation API 的拦截边界先划清

入口是 window.navigation。它面向当前浏览上下文的同源历史条目，navigate 会覆盖比“监听链接点击”更完整的导航来源。可是下载、片段跳转、跨源导航并不应该交给 SPA 路由。接管前先做边界判断，能避免把文件下载或页面内锚点误当成业务路由。

用 intercept 统一处理链接和历史导航

下面的示例只接管 /articles/ 路径。代码里的函数是项目需要自行实现的视图层方法，示例重点是事件边界与异步生命周期。

if ("navigation" in window) {
  navigation.addEventListener("navigate", (event) => {
    // 不接管跨源、片段跳转和下载，让浏览器保留默认行为。
    if (!event.canIntercept || event.hashChange || event.downloadRequest !== null) {
      return;
    }

    const url = new URL(event.destination.url);
    // 只把本站文章路由交给 SPA，避免吞掉其他页面。
    if (!url.pathname.startsWith("/articles/")) return;

    event.intercept({
      async handler() {
        // URL 已进入目标条目，先展示占位状态再请求内容。
        renderArticlePagePlaceholder();
        const data = await getArticleContent(url.pathname);
        // 请求失败会让导航进入 navigateerror，交给统一错误层处理。
        renderArticlePage(data);
        event.scroll();
      },
    });
  });
} else {
  // 旧浏览器继续使用项目已有的 History API 或整页导航方案。
  enableHistoryApiFallback();
}

这里不需要再手写 pushState() 来模拟每一种入口。调用 intercept() 后，浏览器负责提交新的历史条目；处理器返回的 Promise 完成后，导航才算完成。主内容渲染完再调用 event.scroll()，可以让滚动位置与新页面状态保持一致。

把 URL、数据和视图状态绑定起来

建议把路由解析和视图渲染分开：destination.url 只负责决定去哪，数据加载函数只接受经过解析的路径，渲染函数不直接修改历史记录。这样后退与前进仍然复用同一条处理链，排查时也能明确是 URL、请求还是组件状态出了问题。

兼容性与失败处理不能省略

Navigation API 不会在首屏加载时自动触发 navigate，因此应用启动时应直接根据 location 或 navigation.currentEntry 渲染一次。异步加载失败时让 Promise 拒绝，并在 navigateerror 中记录可读提示；不要在错误分支里悄悄把地址改回旧路径。部署时保留 History API fallback，才能覆盖尚未支持该 API 的浏览器。

常见问题

为什么点击链接没有进入 intercept？

先检查是否在支持 Navigation API 的浏览器中，再确认 URL 是否跨源、是否为下载或 hash 变化；这些情况可能被代码主动放行。

intercept 和 preventDefault 有什么区别？

preventDefault() 是取消导航，intercept() 是接管导航后的处理过程。SPA 通常需要后者完成加载和渲染，而不是简单阻止地址变化。

是否可以继续使用 History API？

可以。Navigation API 更适合统一监听和管理现代 SPA 导航，但兼容降级仍可使用项目现有的 pushState、popstate 方案。