不能混合使用hash和history模式，因浏览器统一管理URL解析与历史栈，两者事件（popstate与hashchange）会相互干扰，导致路由状态错乱、前进后退不可预测，且主流路由库均强制单模式启动。
不能混合使用 hash 和 history 模式——浏览器只允许一种路由机制生效，强行共存会导致 popstate 与 hashchange 事件互相干扰、路由状态错乱、前进/后退行为不可预测。
为什么不能在同一个页面里同时启用两种路由模式
根本原因在于：URL 解析和历史栈管理由浏览器统一控制，history.pushState() 修改的是整个 URL（不含 hash），而 window.location.hash 只读写 # 后部分。当两者同时被代码操作时：
- 调用
pushState('/about')后再改location.hash = '#user'，实际 URL 变成/about#user，但popstate事件不会触发，hashchange却会——路由库若监听了两者，就会重复渲染或漏响应 -
history.back()仅回退到上一个pushState记录，完全忽略 hash 变化；而用户手动修改地址栏 hash 时，history.state不变，导致组件状态与 URL 不一致 - 所有主流路由库（Vue Router、React Router、SvelteKit）内部都强制选择一种模式启动，初始化后禁止切换 —— 这不是限制，而是对浏览器行为的必要封装
静态结构设计应优先确定部署环境，而非“兼顾两种模式”
所谓“结合”，其实是根据服务器能力做取舍，不是技术上并行启用：
- 若部署在无配置权限的静态托管平台（如 GitHub Pages、Vercel 默认设置、Netlify 的简单部署），必须用
hash模式——它不依赖服务器重定向，刷新https://site.com/#/user始终返回index.html - 若可控 Nginx/Apache，且能配置 fallback（例如所有非资源请求都返回
index.html），才可安全启用history模式，URL 更干净，SEO 更友好 - 混用诉求往往来自“开发想用 history，但上线怕 404”，这时正确做法是：开发阶段用本地服务模拟 history 行为（如 Vite 的
server.historyApiFallback），上线前统一配服务器 fallback，而不是在代码里埋两套监听逻辑
真需要过渡或降级时，只应在入口层做单向 fallback
极少数场景（如 legacy 子应用嵌入新主应用）需兼容旧 hash 链接，但仍是单向处理：
立即学习“前端免费学习笔记（深入）”；
- 主应用用
history模式运行，启动时检查window.location.hash是否存在且非空；若有，用history.replaceState()把它转成 clean URL，并立即导航，之后完全交由popstate管理 - 绝不监听
hashchange并同步更新history—— 这会导致两次 push，历史栈污染 - 示例逻辑：
if (window.location.hash && window.location.hash.startsWith('#/')) { const path = window.location.hash.slice(1); history.replaceState(null, '', path); router.push(path); // 触发一次正常 history 导航}
真正容易被忽略的点是：路由模式不是功能开关，而是部署契约。选 hash 就接受 URL 里的 #；选 history 就必须确保服务器对所有前端路由路径返回 index.html。任何试图在 JS 层“揉在一起”的方案，最终都会在刷新、分享、后退时暴露状态不一致问题。
