前端路由的演进史：从 hash 到 History API 再到文件式路由

在传统的多页应用中，点击一个链接，浏览器会向服务器请求一个新的 HTML 文档，整个页面刷新。这种体验在网速慢或页面复杂的场景下，有明显的卡顿和闪烁。SPA 的初衷就是把应用“装”在一个页面里，通过 JavaScript 动态切换视图，带来类似桌面应用的流畅感。但浏览器默认的导航行为会破坏这种体验，因此，前端必须“劫持”URL 变化的控制权——在 URL 改变时，阻止浏览器发请求，转而执行我们自己的 JavaScript 代码，去渲染对应的组件。这就是前端路由最原始的动力。

第一幕：Hash 模式，在夹缝中求生存

早期，浏览器并没有给前端开发者直接操作 URL 路径而不刷新页面的权限。但聪明的工程师们发现了一个“后门”：URL 中的 hash（即 `#` 及后面的部分）。

改变 `location.hash` 的值，浏览器会将其记录到历史堆栈中，但不会向服务器发送请求。同时，浏览器提供了 `hashchange` 事件来监听这一变化。这简直是为 SPA 量身定做的特性。于是，第一代前端路由方案诞生了：Hash 模式。

它的实现原理非常直接：

1. 定义一套规则，将 `#/home`、`#/about` 这样的 hash 值与具体的组件或页面函数映射起来。
2. 页面加载时，读取当前的 hash，渲染对应的视图。
3. 监听 `hashchange` 事件，当 hash 变化（无论是通过代码设置、用户点击带 `#` 的链接，还是浏览器前进后退）时，解析新的 hash，找到匹配的组件并渲染。

下面是一个极简的实现，能让你看清它的本质：

class HashRouter {
  constructor() {
    this.routes = {};
    // 核心：监听 hash 变化
    window.addEventListener('hashchange', () => this.handleRouteChange());
    // 初始加载也要处理
    window.addEventListener('load', () => this.handleRouteChange());
  }

  addRoute(path, callback) {
    this.routes[path] = callback;
  }

  handleRouteChange() {
    // 去掉 # 号，得到路径，如 /home
    const path = window.location.hash.slice(1) || '/';
    const handler = this.routes[path];
    if (handler) {
      handler(); // 执行渲染逻辑
    }
  }
}

Hash 模式迅速流行起来，因为它简单、兼容性极好（直到 IE8），且完全不需要后端配合，静态服务器就能托管。但它的缺点也同样明显：URL 里那个丑陋的 `#` 符号，对搜索引擎不友好，并且无法利用服务器端路由的许多特性。

第二幕：History API，走向“正规军”

HTML5 带来了 `History API`，特别是 `pushState()` 和 `replaceState()` 方法，彻底改变了游戏规则。它们允许开发者直接修改浏览器的历史记录和当前 URL，而不会触发页面刷新。

这意味着，前端终于可以创造出像 `example.com/about` 这样干净、真实的 URL，而不再需要 `#`。用户体验和 SEO 友好性得到了质的提升。这就是 History 模式。

但权力越大，责任也越大。History 模式引入了一个关键问题：它需要后端配合。因为当用户直接访问 `example.com/about` 或刷新这个页面时，浏览器会向服务器发起一个对 `/about` 路径的请求。如果服务器没有针对这个路径返回 `index.html`（你的 SPA 入口文件），就会返回 404。

因此，使用 History 模式时，必须在服务器端配置“回退到 `index.html`”的规则。无论是 Nginx、Apache 还是 Node.js 服务器，都需要确保所有前端路由路径最终都指向同一个 HTML 文件。

History 模式的实现，核心是监听 `popstate` 事件（处理浏览器前进后退）和拦截链接点击（使用 `pushState` 改变 URL 并更新视图）：

class HistoryRouter {
  constructor() {
    this.routes = {};
    // 核心：监听浏览器前进后退
    window.addEventListener('popstate', (e) => this.handleRouteChange(e.state?.path));
    // 拦截所有链接点击，防止默认跳转
    document.addEventListener('click', (e) => {
      if (e.target.tagName === 'A') {
        e.preventDefault();
        const href = e.target.getAttribute('href');
        this.navigate(href);
      }
    });
    this.handleRouteChange(window.location.pathname);
  }

  navigate(path) {
    // 使用 pushState 改变 URL，不刷新页面
    window.history.pushState({ path }, '', path);
    this.handleRouteChange(path);
  }

  handleRouteChange(path) {
    const handler = this.routes[path];
    if (handler) {
      handler();
    }
  }
}

History 模式让前端路由从“奇技淫巧”变成了“标准实践”，但也将路由的复杂性从纯前端扩展到了前后端协作的层面。

两种模式的工程抉择

在实际项目中，如何选择 Hash 模式还是 History 模式？这从来不是单纯的技术优劣问题，而是工程场景的权衡。

很多团队在开发内部管理系统时，为了部署简单，依然会选择 Hash 模式。而面向消费者的产品，则会毫不犹豫地采用 History 模式，并配套 SSR 方案来解决首屏加载和 SEO 问题。

第三幕：文件式路由，声明式的未来

随着 React、Vue 等框架的成熟，路由库（React Router、Vue Router）对 Hash 和 History 模式进行了精良的封装，让开发者无需再关心底层实现。但路由的配置方式依然繁琐——你需要在代码中显式地声明一个庞大的路由映射表。

于是，以 Next.js（App Router）、Nuxt.js、Remix 等为代表的现代全栈框架，带来了下一代路由范式：文件式路由（File-based Routing）。

它的核心理念是“约定大于配置”：文件系统的结构就是你的路由结构。在 `app` 或 `pages` 目录下创建一个 `about/page.tsx` 文件，就自动生成了 `/about` 路由。创建 `blog/[id]/page.tsx`，就定义了一个动态路由 `/blog/:id`。

这种模式带来了几个根本性的变化：

1. 开发体验的飞跃：添加页面就是创建文件，无需修改中心化的路由配置文件，减少了心智负担和合并冲突。
2. 路由与数据获取深度集成：在文件式路由中，每个路由文件不仅可以导出 UI 组件，还可以导出 `loader`、`action` 等函数，用于在渲染前获取数据或处理表单提交。路由成为了数据流的一部分。
3. 服务器组件与客户端组件的自然划分：像 Next.js 这样的框架，允许你在同一个路由文件中混合使用在服务器端渲染的组件和在客户端交互的组件，文件式路由为这种混合渲染模型提供了清晰的物理边界。

文件式路由看似只是简化了配置，实则反映了前端架构思维的转变：从“命令式地告诉框架如何做”，转向“声明式地描述应用的结构和需求”，将更多的复杂性和优化工作交给框架和编译器。

演进背后的逻辑与未完的挑战

回顾前端路由从 Hash 到 History 再到文件式的演进，其主线非常清晰：在追求更佳用户体验和开发体验的同时，不断模糊前端与后端、客户端与服务端的边界。

Hash 模式是纯前端的妥协方案。History 模式将路由的“形”变成了真实路径，但“实”仍在客户端。而现代的文件式路由，配合 SSR、SSG、边缘计算，正在将路由重新变成一个由前后端共同参与、甚至由编译时决定的混合概念。

这个演进过程也带来了新的挑战：

• 复杂性转移：配置的复杂性降低了，但对框架和构建工具的理解深度要求提高了。
• 调试难度增加：文件式路由和服务器组件使得代码的执行环境变得不确定，传统的浏览器调试工具有时会力不从心。
• 迁移成本：对于存量的大型项目，向文件式路由迁移是一项庞大的工程。

展望未来，路由系统可能会进一步与状态管理、数据缓存、权限模型更紧密地结合，成为一个应用级的“智能导航中枢”，而不仅仅是路径到组件的映射器。对于开发者而言，理解这段演进史，不仅能帮助我们更好地使用现有工具，更能让我们在面对未来新的路由范式时，看清其设计意图与演进方向。