HTML哈希（#）是SPA无刷新路由的原始实现机制，通过监听hashchange事件响应URL锚点变化，初始化需手动处理location.hash，其与history.pushState路由在服务端配置、SEO、兼容性和URL形式上存在关键区别。
HTML哈希（#）是前端路由的原始实现机制之一
是的，HTML哈希和前端路由有直接关系——在 History API 普及前，location.hash 是单页应用（SPA）实现无刷新路由的核心手段。它不触发页面重载，浏览器会把 #xxx 部分当作 URL 的“锚点”，但允许 JS 监听变化并响应。
怎么用 hashchange 事件监听路由变化
现代浏览器都支持 window.addEventListener('hashchange', handler)，但它只在 location.hash 真正改变时触发（比如用户点击链接、调用 location.hash = 'xxx'），不会在页面首次加载时触发。
常见错误现象：
- 页面一打开就该显示 /home，但
hashchange没触发 → 需手动调用一次路由处理逻辑 - 用
history.pushState改了 URL 却没改 hash →hashchange完全不响应
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 初始化时读取
location.hash.slice(1)（去掉 # 号）作为当前路径 - 监听
hashchange后同样用location.hash.slice(1)获取新路径 - 避免直接操作
document.location.href赋值，可能引发两次 history 记录
示例：
function renderView(path) {
document.body.innerHTML = `<h2>当前视图：${path || 'home'}</h2>`;
}
<p>// 初始化
renderView(location.hash.slice(1) || 'home');</p><p>// 监听变化
window.addEventListener('hashchange', () => {
renderView(location.hash.slice(1));
});
hash 路由和 history.pushState 路由的关键区别
二者都能实现 SPA 导航，但行为差异直接影响部署和 SEO：
-
hash路由：URL 形如https://site.com/#/user/123，# 后内容不发给服务器 → Nginx/Apache 不需要特殊配置，但搜索引擎传统上忽略 hash 后内容 -
pushState路由：URL 形如https://site.com/user/123，需服务端配置 fallback（如所有非静态资源请求返回index.html），否则刷新 404 - 兼容性：
hash在 IE8+ 全支持；pushState需 IE10+ - URL 干净度：
hash路由的 URL 带 #，对分享、可读性略差
为什么现在还要了解 hash 路由
不是因为它更先进，而是它依然在特定场景不可替代：
- 静态托管环境（如 GitHub Pages、Vercel static mode）无法配置服务端 fallback，
hash是最稳妥选择 - 微前端子应用嵌入主应用时，为避免路由冲突，常主动启用
hash模式隔离 - 某些老项目或轻量工具库（如早期 Vue Router 默认模式）仍默认使用
hash - 调试时快速模拟路由跳转：
location.hash = '#/debug'一行就能触发，比 mock history 更直接
容易被忽略的一点：hash 值会被浏览器计入 history 记录，但它是“可跳过”的——连续多次设置相同 hash，只会保留最后一次，不像 pushState 每次都新增一条记录。
