location.hash本身不干扰前端路由，但混用或误操作会导致路由失效、白屏等问题；首次加载需主动处理已有hash值，解析前须decodeURIComponent，框架hash模式下禁止手动修改location.hash。
location.hash 本身不会“影响”前端路由，但混用、误读或忽略其行为边界时，会直接导致路由失效、白屏、重复渲染或状态丢失——尤其在 Vue Router、React Router 等框架中启用 mode: 'hash' 后又手动操作 location.hash，问题几乎必然出现。
哈希值变化不触发 hashchange 怎么办
页面首次加载时，location.hash 已有值（比如从书签或外部链接带 #user/123 进来），但 hashchange 事件根本不会触发。这是最常被忽略的初始化断点。
- 必须在监听前主动执行一次路由处理：比如
handleRoute(location.hash) - 不要只写
window.addEventListener('hashchange', ...)就以为万事大吉 - IE9 及更早需用
window.onhashchange = handler，而非addEventListener
哈希参数含编码字符（如 %2F）怎么解析
location.hash 返回的是原始字符串，#user%2F123 中的 %2F 不会自动解码。直接 slice(1).split('/') 会切出 ['user%2F123']，而不是 ['user', '123']。
- 务必先调用
decodeURIComponent(hash.slice(1))，再做路径分割或正则匹配 - 若解析失败（比如遇到非法 UTF-8 编码），
decodeURIComponent会抛URIError，需包裹try/catch - 避免用
URLSearchParams解析哈希参数——它只认search部分，对hash无效
Vue Router / React Router 开启 hash 模式后还能自己改 location.hash 吗
不能。框架的 router.push('/user/123') 内部已封装了 location.hash 更新逻辑，并维护了内部 history.state 和组件激活状态。你再手动赋值 location.hash = '#order/456'，会导致：
- 路由组件未更新（框架没感知到这次变更）
- 前进/后退按钮行为异常（历史栈与框架状态错位）
- 重复触发
hashchange，引发两次渲染甚至无限循环
所有跳转必须走框架 API：router.push()、router.replace()，而不是碰 location.hash。
立即学习“前端免费学习笔记（深入）”；
刷新页面后哈希路由白屏或 404 是为什么
因为服务端完全看不到 # 后的内容。用户访问 https://site.com/#dashboard，Nginx 实际收到的请求是 GET /；但若用户直接刷新，而 HTML 文件没部署在根路径（比如部署在 /app/ 子目录），且 Nginx 未配置 fallback，就可能返回 404 或加载错资源。
- 确保 HTML 入口文件能被
GET /（或对应子路径）正确返回 - Nginx 配置中不需要为哈希路由加
try_files——那是给 history 模式用的 - 真正要检查的是：静态资源路径（
script、css）是否用了相对路径导致 404，比如src="./js/app.js"在/app/#home下会请求/app/js/app.js，而非/js/app.js
location.hash——它不发声，但一上来就决定你整个路由系统能不能活。 
