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），也不受服务端路由识别 -
使用隐藏的
<iframe></iframe>+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 语义和响应策略上达成一致。
