前端路由 Hash 与 History 模式详解

因此，hash 模式特别适合内部使用的后台管理系统、原型演示项目，或需要兼容 IE8 以下浏览器的老旧项目。

二、history 模式：借助 HTML5 History API 的'真'URL

1. 什么是 history 模式？

history 模式利用 HTML5 新增的 History API，让 URL 看起来和普通多页应用完全一样，没有 # 号。例如 http://www.example.com/user/123，这种格式更符合用户的直觉。

2. 工作原理

History API 提供了 pushState() 和 replaceState() 方法，它们可以修改浏览器的历史记录栈，同时改变地址栏的 URL，但不会触发页面刷新。配合 popstate 事件，我们就能在用户点击前进/后退时更新视图。

一个简单的实现如下：

// 切换到 /user/123 并添加历史记录
history.pushState({userId: 123}, null, '/user/123');
// 监听 popstate 事件（仅当用户点击前进/后退时触发）
window.addEventListener('popstate', (event) => {
  // event.state 中包含了 pushState 设置的 state 对象
  renderComponent(location.pathname, event.state);
});

注意，pushState() 本身不会触发 popstate 事件，所以代码切换路由时需要手动调用渲染函数。

3. 特点与后端配置的必要性

history 模式的 URL 是真实的路径，因此当用户直接访问 http://www.example.com/user/123 或刷新页面时，浏览器会向服务器请求这个路径。如果服务器上没有对应的资源，就会返回 404。为了解决这个问题，必须对后端进行配置：将所有未匹配到静态文件的请求都指向同一个入口文件（通常是 index.html），由前端路由接管路径解析。例如，在 Nginx 中可以这样配置：

location / {
  try_files $uri $uri/ /index.html;
}

这样的配置意味着服务器始终返回 index.html，然后前端代码根据当前路径渲染对应的组件。

4. 优势与局限

与 hash 模式相比，history 模式的优势非常突出：

• URL 简洁美观：没有 #，更符合标准 URL 的规范。
• 可传递复杂状态：pushState() 的 state 参数可以携带任意 JavaScript 对象，方便在页面间传递数据。
• 支持相同 URL 记录：可以多次将同一个 URL 加入历史栈（例如用户多次点击同一个链接），而 hash 模式要求 hash 值必须不同才会新增记录。
• 可利用 title 属性：虽然目前大多数浏览器忽略 title 参数，但为未来优化留出了空间。

它的局限性主要在于：

• 需要服务器配合：如果后端没有正确配置，刷新或直接访问就会导致 404。
• 兼容性略低：IE9 及以下不支持 History API，但现代项目中这已不成问题。
• 实现相对复杂：但 Vue-Router 等库已经完美封装，开发者几乎感受不到差异。

三、两种模式的深度对比

为了更清晰地理解它们的差异，我们可以从几个关键维度进行对比：

除了以上表格，原文章中提到的 pushState() 相对于 hash 的几个优势值得我们再次强调：

• 同源任意 URL：pushState() 可以设置同源下的任何路径，而 hash 只能修改当前文档的片段，灵活性更高。
• 相同 URL 也记录：即使新 URL 与当前 URL 完全相同，pushState() 也会在历史栈中新增一条记录，这在某些交互场景中非常有用。
• 可附加状态数据：通过 state 对象，我们可以将页面状态与历史记录绑定，用户在返回时能恢复到之前的状态，而不仅仅是路径。
• 可设置标题：虽然目前支持有限，但这是未来可能的增强点。

四、如何在项目中做出选择？

在实际开发中，选择哪种模式并没有绝对的对错，而是需要结合项目具体需求来权衡。以下是一些常见的考量因素：

1. 浏览器兼容性要求

如果项目需要支持 IE9 及以下浏览器，那么只能使用 hash 模式。不过，随着微软对旧版 IE 停止支持，大多数现代项目已无需考虑这一点。

2. 后端配置权限

如果你无法控制服务器配置（例如使用 GitHub Pages、某些云存储静态网站托管），hash 模式是更稳妥的选择。GitHub Pages 虽然可以通过配置支持 history 模式，但需要额外的步骤（如使用 404 页面作为 fallback），不如 hash 模式开箱即用。

3. URL 美观需求

如果产品需要对外分享链接，或者对用户体验有较高要求，history 模式的干净 URL 会更受欢迎。例如，电商网站的商品详情页使用 /product/123 显然比 /#/product/123 更专业。

4. SEO 要求

虽然 SPA 的 SEO 本身需要借助服务端渲染（SSR）或预渲染来解决，但 history 模式的 URL 更容易被搜索引擎识别和索引。如果未来计划做 SSR，history 模式也是自然的选择。

5. 功能需求

如果需要在路由切换时携带复杂的状态（如表单数据、滚动位置），history 模式的 state 对象会带来极大便利。而 hash 模式只能靠拼接字符串，不仅麻烦，还有长度限制。

综合来看，对于大多数新项目，尤其是那些有后端配置权限、追求良好用户体验的应用，history 模式是更推荐的选择。而对于简单原型、内部工具或部署环境受限的项目，hash 模式依然是一个简单可靠的备选方案。

五、扩展知识：HTML5 History API 的其他能力

除了 pushState 和 replaceState，History API 还提供了以下方法用于控制历史导航：

• history.back()：后退一步，等同于点击浏览器后退按钮。
• history.forward()：前进一步。
• history.go(n)：相对当前页前进或后退 n 步（n 可为负数）。

这些方法都会触发 popstate 事件（除非 n=0），让我们能够统一处理用户导航。

另外，history.length 属性表示当前会话中的历史记录总数，而 history.state 可以获取当前页面的状态对象，方便随时读取。

值得一提的是，pushState() 和 replaceState() 不会触发 popstate 事件，但会更新 history.state。因此，当我们用代码切换路由时，通常需要手动调用渲染函数，并可能结合 history.state 来传递数据。

参考链接：

• MDN: History API
• Vue Router 官方文档