HTML哈希能否提升前端路由_HTML哈希改善前端路由效果解析

哈希路由不是性能优化手段，而是历史兼容方案；它不触发网络请求，但卡顿常源于全量重渲染、未节流hashchange、低效字符串匹配及漏监听load事件。

不能提升，只会妥协。 HTML 哈希（location.hash）不是性能优化手段，而是历史兼容方案——它不加速路由，也不增强功能，只是在服务端不可控、浏览器太老、部署太糙时，让前端路由“还能跑起来”。

哈希模式根本没走网络请求，为什么还会卡？

哈希变化本身不触发请求，但常见卡顿来自手动实现逻辑的低效：

• 每次 hashchange 都全量重渲染整个视图区域，而不是按需更新组件
• 未节流高频 hash 变化（比如用户狂点链接或快速拖拽 URL 栏），导致重复解析和渲染
• 用 location.hash 字符串做 switch 或 if 判断，却没预编译成 Map 或正则，字符串匹配开销随路由数线性增长
• 初始加载时漏掉 load 事件监听，靠 setTimeout 模拟首次匹配，造成白屏延迟

React Router 中用 mode: 'hash' 还要自己监听 hashchange 吗？

完全不需要，而且绝对不要这么做。React Router v6 的 createBrowserRouter 不支持 mode: 'hash'；若你看到这个配置，说明还在用 v4/v5 的 HashRouter。

• v6 已移除 HashRouter，官方推荐用 createBrowserRouter + 服务端 fallback，或降级用 createHashRouter（v6.10+ 新增）
• 用了 createHashRouter 就别再手动 window.addEventListener('hashchange', ...)，否则会和内部监听冲突，造成 useLocation() 返回值滞后、navigate() 失效、状态不同步
• useLocation().hash 返回的是带 # 的完整字符串，提取路径必须写 location.hash.slice(1)，不是 location.hash.replace('#', '')（后者对 ##user 这类非法但可能存在的输入会出错）

哈希路由刷新就 404？这其实是部署误解

哈希路由本身不会 404——https://example.com/#/user/123 刷新后，浏览器只向服务器发 GET /，只要返回 index.html 就能正常启动。所谓“404”，往往是因为：

立即学习“前端免费学习笔记（深入）”；

• 你误以为自己在用哈希路由，实际配置了 History 模式（比如 createBrowserRouter 却没配服务端 fallback）
• 静态托管平台（如 GitHub Pages）没启用 404.html fallback，导致访问子路径如 /user 时返回 404 页面而非 index.html
• 你在 Nginx/Apache 上错误地加了哈希相关的 rewrite 规则（哈希根本不需要服务端参与，加了反而干扰）

真正容易被忽略的点是：哈希路由下，history.state 是空的，所有导航都丢失 scroll position 和自定义 state；如果你依赖 scrollRestoration: 'manual' 或 state 传参，哈希模式天然不支持——这不是 bug，是设计使然。