前几天在辅导一个同学的时候，他突然问我一句：

“为什么很多单页应用默认都是 hash 路由呀？现在不是都推荐用 history 路由了吗？”

这问题看似简单，但其实特别能看出一个人对前端工程化和部署链路理解得透不透。

作为一个做了 10 多年前端的老兵，我自己第一次部署 Vue 项目的时候就被这个问题坑得不轻。今天就来聊聊：

• 前端路由到底分哪几种？
• hash 路由看起来“老土”，为什么它反而经常能保你一命？
• 在实际项目中怎么做权衡？

一、前端路由的两种主流模式

前端路由本质是：URL 和视图的映射关系，但在实现机制上，大致可以分成两类：

1. hash 路由（/#/home）

• 利用了浏览器 URL 中的 # 锚点，它后面的部分不会被服务器解析
• 页面刷新不会触发后端请求

2. history 路由（/home）

• 基于 HTML5 的 pushState / replaceState
• 路径看起来更“干净”，但刷新时会请求服务器，服务端需要做特殊配置

这部分知识不复杂，但“用在哪里”、“为什么这么用”，就见仁见智了。

二、用 history 路由把自己坑惨……

刚接触 Vue 的时候，信心满满用 Vue Router 配了 mode: 'history'，本地跑得没问题，部署上服务器之后，刷新页面直接 404。

当时后端同事直接一句：

“你这个路径 /about 根本不是我后端接口，当然报 404 啊。”

这时候我才意识到，history 路由需要服务端做 fallback 配置：无论访问哪个路径，都要返回 index.html，让前端接管路由。

后来我们是在 nginx 加了一句：

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

才搞定的。那次踩坑之后我就特别清楚：

如果你没法控制服务端配置，hash 路由就是最稳的选择。

三、hash 路由的“土办法”，其实是工程上的稳妥

很多人一开始会嫌弃 hash 路由“URL 丑”、“看起来不高级”。但真实项目里，我见过太多新手写的项目，部署上线就炸——原因就是用了 history 路由但服务端没配 fallback。

相反，用 hash 的，几乎从来不会出这种问题。为啥？

• hash 后面的内容不会被服务器识别，天然避免了刷新 404；
• CDN 或 OSS 静态托管环境（比如阿里云 OSS），默认就是支持 hash 路由的，history 会直接挂；
• 移动端 H5 项目、内嵌 WebView 的小程序，也基本默认用 hash，稳定性第一；

团队里现在的做法是：低成本项目默认用 hash，toB 项目或能配服务器的再考虑 history。

四、hash 路由在面试中也很容易成为“隐形加分项”

我面试别人时不会直接问“你了解 hash 路由吗？”但我会问：

“你部署的项目中路由是怎么配置的？有没有踩过什么坑？”

答得好的，基本都能讲出 hash 和 history 的区别，甚至有些人还能聊聊 nginx 的配置、CDN 的兼容性，这种候选人我会多看一眼。

而这种思路，我们在【前端面试题宝典】小程序中，就有很多类似的场景题，很多人刷完题后给小助手反馈：

“原来这种看起来简单的知识点，其实背后有好多坑，确实容易被忽略。”

如果你最近也在准备跳槽或者系统复盘知识，可以去刷一刷：https://fe.ecool.fun?ic=M9KOQQ，小程序搜“前端面试题宝典”也能找到。

五、最后我怎么看 hash 和 history？

说白了，hash 路由不是落后，只是更稳。

真实项目里永远是“能上线稳定跑”第一，URL 美不美、技术潮不潮，永远排在后面。除非你能全链路控制部署环境，否则 hash 是更保险的选择。

当然，技术演进是方向，像我们现在用的微前端框架 qiankun，子应用如果是 hash 模式，主应用要额外处理兼容；这个时候 history + nginx fallback 是更专业的做法。

所以回到最初的问题：

“为什么现在 SPA 还在用 hash？”

不是因为技术落后，而是因为项目落地需要稳。

总结一下

1. hash 路由的本质优势，是刷新不报错，和服务器无耦合
2. 新手项目、无法配服务器的静态部署环境，hash 是首选

如果你看到这里，还在犹豫到底该用 hash 还是 history，不妨问问自己两个问题：

• 我能不能配服务器的 fallback？
• 我的项目是否对 URL 美观性有要求？

想得通这两个问题，也就明白该怎么选了。

欢迎在评论区聊聊你踩过的部署坑，或者你觉得哪种路由模式更适合你们团队。我也会继续分享一些面试辅导里常见的“掉坑知识点”，关注我，不迷路。