如果把单页应用比作一座功能齐备的大别墅，那么前端路由就是这座别墅里的“导览员”。当你在地址栏输入 URL 时导览员会根据地址，精准地把对应的页面组件搬到你的眼前。不过，面对两种主流的导览方式——老成持重的 Hash 模式 与现代时髦的 History 模式很多初学者往往只知道名字。却不知道它们各自的优缺点，导致面试被问到区别时卡壳、项目选型时犹豫不决。

什么是路由

路由，本质上就是描述服务器上资源方法的一串地址。说起来，当你在浏览器里敲下一个 URL。后端会根据这个方法找到对应的资源，接下来返回给你。

但到了前端，事情变得有点不一样。

前端路由的观点是。让 URL 和组件建立映射

现在的主流架构是 SPA ——整个应用只有一个 HTML 页面切换“页面”时不再向服务端发起整页请求，而是由 JavaScript 动态替换当前页面的内容。

这时候问题就来了：页面没刷新。但使用者看到的却是不同的“页面”，那 URL 怎么办？

前端路由的本质。就是建立浏览器 URL 地址和组件之间的映射关系——URL 变了渲染对应的组件，页面本身不刷新。

怎么实现“改 URL 但不刷新页面”

浏览器给了我们两条路：

一、Hash 模式

在浏览器眼里URL 中 # 后面的部分叫做 hash。再看关键点在于，hash 的变更不会触发页面刷新这是浏览器天生的行为。

常见痛点： · 初学者经常误以为可以随意使用 #/xxx 而忽略了 SEO 与可读性的问题 · 部分旧项目因为兼容性需求只能硬撑 Hash。却又想要更干净的 URL，却找不到折中方案。怎么说呢，

// 定义路由映射表
const routes =;// 监听 hash 变化
window.addEventListener => {
renderView;})，function renderView {
for {
if {
document.getElementById.innerHTML = routes.component;break，}
}
}

优点：

• 兼容性好，实现简单。
• 不需要服务器任何配置，直接放到静态文件服务器上即可运行。

缺点：

• URL 中永远带着 # ——看起来不够专业，也会影响部分搜索引擎抓取。
• # 后面的内容不会发送到服务器，有时会导致后台日志缺失真实访问方法。

二、History 模式

HTML5 为 window.history 对象新增了几个 API。让前端可以直接操控浏览器历史记录而不触发页面刷新：

pushState // 向历史记录栈添加一条记录
popState // 浏览器后退/前进时触发事件
replaceState // 替换当前栈顶记录

Pain point： · 开发者常忘记在服务器侧做 fallback 配置，以致使用者直接刷新的深层方法出现 404； · 对于 SSR 项目，需要同时处理客户端和服务端渲染。两套路由保持同步是一大挑战。

const routes =;// 页面首次加载
window.addEventListener => onLoad);// 浏览器前进后退事件
window.addEventListener => {
renderView;})，function onLoad {
const linkList = document.querySelectorAll;linkList.forEach(el => {
el.addEventListener('click',e => {
e.preventDefault;// 阻止默认跳转
history.pushState);renderView，});})，}
function renderView {
const match = routes.find;if {
document.getElementById.innerHTML = match.component;} else {
document.getElementById.innerHTML = '

404 Not Found
';}
}

• No #。URL 与传统多页应用保持一致，更友好 SEO 与使用者体验。怎么说呢，
• Clever navigation – 可以利用原生 forward/back 按钮。实现完整历史栈管理，

• Pain point: 需要服务器配合，把所有可能的方法统一返回同一个入口文件（如 /index.html)。否则直接访问或刷新深层方法会出现 “404”。
• Slightly higher learning curve – 要理解 pushState/popstate 的细节还有回退策略。

如何在项目中抉择？实战 Checklist

• #1：目标网站是否需要 SEO？If yes → History 模式 + Server‑Side Fallback.
• #2：团队对服务器设置是否熟悉？If server is static → Hash 模式.
• #3：产品对 URL 可读性要求有多高？# 为关键业务建议 History，否则可接受 Hash.
• #4：是否需要兼容老旧浏览器？# 必须使用 Hash.
• #5：团队已有框架封装默认使用哪种模式？# 大多数框架默认 History，可通过配置切换为 Hash.

与常用方法

Hash 模式： 简单粗暴、兼容性强、几行代码搞定；按理说，适合原型、内部程序或只能使用静态托管的网站。但它留下的 “#” 会让使用者和搜索引擎产生疑惑。

History 模式：。