前端路由的两种实现方式是_hash模式和history模式,核心区别在于URL是否含#、是否需服务端配合及兼容性:_hash模式通过location.hash和hashchange事件实现,零服务端要求,兼容IE8+;history模式基于HTML5 History API,URL更美观且利于SEO,但需服务端fallback配置,仅支持IE10+。
JavaScript 通过 window.history API 操作浏览器历史记录,而 _hash 和 history 模式 是前端路由的两种实现方式,核心区别在于 URL 变化是否触发服务端请求、是否需要服务端配合,以及对浏览器历史栈的操作方式不同。
主要使用 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 参数目前多数浏览器忽略,传空字符串即可。
利用 URL 中 # 后面的部分(即 hash)变化来模拟路由,例如 https://example.com/#/user。
hashchange 事件捕获变化:window.addEventListener('hashchange', () => {...})
location.hash = '
/about' 或 history.pushState()(但通常直接改 hash 更简单)index.html),服务器对 /user 或 /admin 不需单独处理# 不够美观;SEO 友好性较差(尽管现代搜索引擎已能抓取部分 hash 内容,但仍不如标准路径)使用 HTML5 History API 实现无 # 的干净 URL,例如 https://example.com/user。
pushState/replaceState 和 popstate 事件,路由变更更接近原生体验/user 或刷新页面时,服务端需将所有非静态资源请求 fallback 到 index.html,否则返回 404try_files $uri $uri/ /index.html;
app.get('*', (req, res) => res.sendFile(indexHtml))
本质差异不在 JS 操作方式,而在 URL 表现、服务端协作要求和兼容性:
#;history 模式是标准路径,更简洁专业hashchange,history API 变更触发 popstate,事件对象和 state 机制不同