HTML5 History API 通过 pushState() 和 replaceState() 实现无刷新 URL 修改与历史管理，配合 popstate 事件响应导航，是 SPA 路由核心；HTML4 无此能力，仅能依赖 hash 或过时 iframe 方案。

HTML5 的 history.pushState() 和 history.replaceState() 怎么用

HTML5 的 History API 允许你在不刷新页面的前提下修改浏览器地址栏、添加或替换历史记录项，是实现单页应用（SPA）路由的核心机制。

关键点在于：这两个方法不会触发页面跳转或重新加载，但会改变 URL 并影响用户点击「后退」「前进」按钮的行为。

• history.pushState(state, title, url)：向历史栈中追加一条新记录。其中 state 是任意可序列化的 JS 对象（会被存入历史状态），title 当前大多数浏览器忽略（传空字符串即可），url 必须与当前域同源（否则抛出安全错误）
• history.replaceState(state, title, url)：替换当前历史记录项，不新增条目——适合更新 URL 但不想让用户多按一次后退
• 调用后，window.location 立即更新，但不会触发 load 或 hashchange 事件；你需要手动渲染对应视图

history.pushState({ page: 'about' }, '', '/about');
// 地址栏变成 https://example.com/about，但页面没重载

history.replaceState({ page: 'contact' }, '', '/contact?ref=nav');
// 替换当前项，后退不会回到 /about

监听 popstate 事件处理浏览器前进/后退

用户点击后退或前进按钮时，浏览器不会自动刷新页面，而是触发 popstate 事件——这是你响应路由变化的唯一时机。

• 该事件只在历史记录被「激活」（即切换到某条记录）时触发，不包括 pushState 或 replaceState 调用本身
• event.state 就是你传入 pushState 或 replaceState 的那个对象，可用于恢复视图状态
• 注意：页面首次加载时（即从服务器直接进入）不会触发 popstate，即使 URL 带有 state 数据

window.addEventListener('popstate', (event) => {
  const state = event.state;
  if (state && state.page === 'about') {
    renderAboutPage();
  }
});

HTML4 能不能控制浏览器历史？

不能。HTML4 没有标准 API 可以编程式地添加、替换或读取历史记录项。

过去常见的“伪方案”只有两种，且都有严重缺陷：

• 修改 location.hash：HTML4 支持，但只能改变 URL 中 # 后面的部分，且仅触发 hashchange 事件（IE8+）。它不改变真实路径，无法支持 SEO 友好的 URL（如 /user/123），也不受服务端路由识别
• 使用隐藏的 + document.write（早期“jQuery BBQ”等库用过）：通过 iframe 的历史操作间接影响父窗口，极其脆弱，兼容性差，现代浏览器已限制或废弃相关行为

所以，如果你需要真正的 URL 控制能力（比如美化路径、服务端直出、PWA 路由），必须依赖 HTML5 History API，且需服务端配合：所有前端路由路径都应返回同一份 HTML（通常是 index.html），否则用户直接访问 /dashboard 会 404。

容易被忽略的兼容性与部署细节

History API 在 IE10+、Chrome 5+、Firefox 4+、Safari 5+ 中可用，但实际落地时几个点常被绕过：

• 服务端必须配置 fallback：当用户直接请求 /product/42 时，不能返回 404，而要返回你的 SPA 入口 HTML，并由前端 JS 解析 URL 再渲染对应内容
• pushState 的 url 参数如果是相对路径，会相对于当前 URL 解析；建议统一用以 / 开头的绝对路径，避免歧义
• 不要依赖 title 参数做页面标题管理——它不生效，应该用 document.title = ... 显式设置
• Android UC 浏览器等旧版 WebView 对 state 对象大小有限制（约 64KB），超限会静默失败，调试时注意检查 history.state

最麻烦的不是写代码，而是让每个前端路由都能被正确索引、分享、刷新而不崩——这要求前后端在 URL 语义和响应策略上达成一致。