前端路由的两种实现方式是_hash模式和history模式，核心区别在于URL是否含#、是否需服务端配合及兼容性：_hash模式通过location.hash和hashchange事件实现，零服务端要求，兼容IE8+；history模式基于HTML5 History API，URL更美观且利于SEO，但需服务端fallback配置，仅支持IE10+。
JavaScript 通过 window.history API 操作浏览器历史记录，而 _hash 和 history 模式 是前端路由的两种实现方式，核心区别在于 URL 变化是否触发服务端请求、是否需要服务端配合，以及对浏览器历史栈的操作方式不同。
如何用 JavaScript 操作浏览器历史记录
主要使用 history.pushState()、history.replaceState() 和 history.back()/history.forward() 等方法：
-
history.pushState(state, title, url)：向历史栈添加一条新记录，不刷新页面，URL 改变（可为相对路径），state 对象会存入该记录中，可用于后续popstate事件读取 -
history.replaceState(state, title, url)：替换当前历史记录，不新增条目，适合更新状态但不想让用户回退到旧状态时（如表单提交后清理参数） - 监听
popstate事件：用户点击前进/后退按钮或调用history.back()时触发，回调中可获取event.state并更新视图 -
history.go(n)、history.back()、history.forward()：控制导航方向，不改变 URL 状态对象
注意：pushState 和 replaceState 中的 url 必须同源，否则报错；title 参数目前多数浏览器忽略，传空字符串即可。
_hash 模式：靠 URL 锚点驱动路由
利用 URL 中 # 后面的部分（即 hash）变化来模拟路由，例如 https://example.com/#/user。
立即学习“Java免费学习笔记（深入）”；
- hash 变更不会导致页面刷新，也不发送网络请求，完全由前端响应
- 通过监听
hashchange事件捕获变化：window.addEventListener('hashchange', () => {...}) - 修改 hash 可用
location.hash = '/about'或history.pushState()（但通常直接改hash更简单） - 无需服务端配置：所有路径都指向同一个 HTML 入口文件（如
index.html），服务器对/user或/admin不需单独处理 - 缺点：URL 中带
#不够美观；SEO 友好性较差（尽管现代搜索引擎已能抓取部分 hash 内容，但仍不如标准路径）
history 模式：真实 URL 路径驱动路由
使用 HTML5 History API 实现无 # 的干净 URL，例如 https://example.com/user。
- 依赖
pushState/replaceState和popstate事件，路由变更更接近原生体验 - URL 看起来像真实路径，利于 SEO 和用户感知
- 必须配合服务端配置：当用户直接访问
/user或刷新页面时，服务端需将所有非静态资源请求 fallback 到index.html，否则返回 404 - 常见服务端配置示例：
- Nginx：添加
try_files $uri $uri/ /index.html; - Vue CLI / Vite：开发服务器默认支持；生产部署需按上述规则配置
- Express：用
app.get('*', (req, res) => res.sendFile(indexHtml))
- Nginx：添加
关键区别总结
本质差异不在 JS 操作方式，而在 URL 表现、服务端协作要求和兼容性：
-
URL 格式：hash 模式强制含
#；history 模式是标准路径，更简洁专业 - 服务端依赖：hash 模式零服务端要求；history 模式必须配置 fallback，否则深层路由刷新失败
- 兼容性：hash 模式支持 IE8+；history 模式需 IE10+（因依赖 HTML5 History API）
-
历史栈行为：两者都可操作历史栈，但 hash 变更触发
hashchange，history API 变更触发popstate，事件对象和 state 机制不同 - 第三方集成：部分分析工具、OAuth 回调、PWA 缓存策略对 history 模式更友好
