History API 如何实现前端路由？有哪些坑？

简化版

History API 通过 pushState、replaceState 和 popstate 在不刷新页面的情况下改变 URL，从而实现 SPA 前端路由。坑主要是刷新 404、后退事件处理、滚动恢复、状态对象大小、服务端兜底和页面标题/SEO。

详细版

前端路由基本流程：

点击链接时阻止默认跳转。
调用 history.pushState 修改 URL。
根据当前路径渲染对应组件。
用户点击后退/前进时监听 popstate，重新渲染。
服务端要把 SPA 路径回退到入口 HTML。

注意点：

pushState 不会自动触发 popstate。
刷新 /user/1 时服务器必须能返回入口页面。
滚动位置需要自己管理或设置浏览器策略。
state 不适合放大对象。
只靠前端路由对 SEO 不友好，内容站更适合独立 URL 静态生成或 SSR。

完整版教学

一、前端路由的本质是 URL 和视图同步

传统页面跳转是浏览器请求新 HTML。SPA 前端路由则是 URL 变化后，前端 JS 根据路径渲染不同视图。History API 的价值是让 URL 看起来像普通路径，例如 /users/1，但切换时不刷新整页。

核心不是 API 本身，而是维持三件事一致：URL、页面组件、历史栈。用户复制链接、刷新页面、点击后退都应该符合预期。

点击 /about
  → pushState('/about')
  → 渲染 About 组件
  → 历史栈新增一条记录

二、pushState 和 replaceState 的区别

pushState 会新增历史记录，适合用户主动导航；replaceState 会替换当前记录，适合重定向、修正 URL、筛选条件初始化等不希望用户后退回去的场景。

数字例子：用户从首页进入列表，再进入详情，使用 pushState 后历史栈增加 2 条，后退能回列表再回首页。如果筛选框每输入一个字都 pushState，输入 10 个字就多 10 条历史记录，后退体验会灾难；这类场景更适合防抖后 replace 或只在确认筛选时 push。

API	是否新增历史	适合场景
pushState	是	页面级导航
replaceState	否	重定向、修正当前 URL
popstate	监听历史变化	后退/前进

三、popstate 只处理用户历史导航

调用 pushState 或 replaceState 本身不会触发 popstate。popstate 通常在用户点击浏览器后退、前进，或代码调用 history.back() 时触发。因此路由库在主动跳转后要自己调用渲染逻辑。

function navigate(path) {
  history.pushState({ path }, '', path)
  render(path)
}

window.addEventListener('popstate', () => {
  render(location.pathname)
})

如果误以为 push 后会自动触发 popstate，页面 URL 变了但视图不变，这是手写路由常见 bug。

四、刷新 404 是服务端没兜底

SPA 中 /user/1 可能只是前端路径。用户首次访问或刷新该地址时，请求会直接打到服务器。如果服务器没有 /user/1 这个真实文件，就会返回 404。解决方式是服务端把这些路径都回退到入口 index.html，再由前端路由接管。

这也是静态站和内容站要谨慎使用纯 SPA 的原因。面试刷题这类 SEO 内容站更适合一题一个真实静态 URL，搜索引擎和用户刷新都更稳定。

五、滚动恢复要设计

用户从列表进入详情，再后退回列表，通常期待回到原滚动位置。浏览器有默认滚动恢复，但 SPA 自己渲染内容、异步加载列表时，默认行为可能不准。可以使用 history.scrollRestoration 或路由层记录滚动位置。

if ('scrollRestoration' in history) {
  history.scrollRestoration = 'manual'
}

实现时要等列表数据和 DOM 恢复后再滚动，否则滚动到的位置可能因为内容尚未渲染而失败。

六、状态对象不要当缓存仓库

pushState 的 state 可以保存少量状态，例如弹窗来源、滚动标记或轻量参数，但不适合放大列表、用户隐私数据或复杂对象。浏览器可能限制大小，历史记录也不是可靠数据存储。

比如把 1000 条商品列表塞进 state，既增加内存，又可能在不同浏览器表现不一致。大数据应放应用状态、缓存层或重新请求，URL 中只保留可恢复页面的关键参数。

记忆钩子：History API 改的是地址栏和历史栈，页面渲染、服务端兜底、滚动恢复都要你自己补上。

七、常见误区与追问

误区：pushState 会自动触发 popstate。 主动 push 不触发，路由需要自己渲染。
误区：前端路由不需要服务端配置。 刷新深路径时服务器必须返回入口页面或真实静态页面。
误区：state 可以存任意大数据。 state 适合轻量状态，不适合缓存大列表和敏感数据。
追问：pushState 和 replaceState 怎么选？ 页面级导航用 push，不希望新增历史记录的修正用 replace。
追问：后退滚动位置错怎么办？ 手动记录滚动，等 DOM 和数据恢复后再滚动。
追问：SPA 路由对 SEO 有什么影响？ 纯客户端渲染对内容 SEO 不友好，SSR/SSG 或真实静态 URL 更稳。

八、加强记忆

History API 用“URL、视图、历史栈”三角来记。pushState 增加历史，replaceState 修正当前，popstate 响应后退前进；刷新深链接靠服务端兜底，滚动和状态恢复靠路由层设计。它不是完整路由框架，只是浏览器给你的底层能力。

简化版

详细版