javascript如何操作浏览器历史记录_hash和history模式有何区别_技术教程

前端路由的两种实现方式是_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。

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))

关键区别总结

本质差异不在 JS 操作方式，而在 URL 表现、服务端协作要求和兼容性：

URL 格式：hash 模式强制含 #；history 模式是标准路径，更简洁专业
服务端依赖：hash 模式零服务端要求；history 模式必须配置 fallback，否则深层路由刷新失败
兼容性：hash 模式支持 IE8+；history 模式需 IE10+（因依赖 HTML5 History API）
历史栈行为：两者都可操作历史栈，但 hash 变更触发 hashchange，history API 变更触发 popstate，事件对象和 state 机制不同
第三方集成：部分分析工具、OAuth 回调、PWA 缓存策略对 history 模式更友好