pushState和replaceState不刷新页面但需手动更新视图，参数顺序为(state, title, url)，url须同源；popstate仅在浏览器导航时触发，首次加载需手动初始化；服务端必须配置fallback路由避免404。
pushState 和 replaceState 怎么用才不刷新页面
直接调用 history.pushState() 或 history.replaceState() 不会触发页面刷新，但也不会自动渲染新内容——这是最常被误解的一点。你得自己监听路由变化、更新 DOM 或组件。
关键参数顺序别写错：pushState(state, title, url) 中的 url 必须同源（协议+域名+端口一致），否则抛出安全错误；title 目前所有浏览器都忽略，传空字符串即可；state 是任意可序列化的 JS 值，会随后续 popstate 事件一起返回。
-
pushState()向历史栈添加新条目（前进/后退可用） -
replaceState()替换当前条目（适合表单提交后清除冗余状态） - 手动修改 URL 后，必须同步更新视图，否则用户看到的是旧内容
popstate 事件监听要注意什么
popstate 只在用户点击浏览器前进/后退按钮，或调用 history.back()/history.forward() 时触发，**不会**在 pushState() 或 replaceState() 调用时触发。
首次加载页面时，即使 URL 已有路径，也不会触发 popstate ——你需要手动读取 location.pathname 初始化视图。
立即学习“Java免费学习笔记（深入）”；
- 务必在页面加载完成后再绑定监听：
window.addEventListener('popstate', handler) -
event.state就是当初传入pushState()的那个对象，可用于恢复滚动位置、表单数据等 - 不要依赖
event.state存大量数据，它会被序列化进浏览器历史，有大小限制（Chrome 约 640KB）
如何避免 History API 导致 404（服务端没配置）
前端路由只管浏览器行为，不解决服务端问题。当用户直接访问 /user/123 或刷新页面时，请求会发到服务器——如果服务器没配 fallback（比如把所有非静态资源请求都返回 index.html），就会返回 404。
开发阶段用 Vite、Webpack Dev Server 通常默认开启 historyApiFallback: true；生产部署时，Nginx 需加配置，Express 需加兜底路由：
app.get('*', (req, res) => {
res.sendFile(path.join(__dirname, 'index.html'));
});- 静态托管平台（如 GitHub Pages、Vercel、Netlify）大多提供「重写规则」配置项，填
/* → /index.html即可 - 不能靠前端 JS 拦截 404：HTTP 状态码由服务端决定，JS 无法改变已发生的响应
和 hash 路由比，History API 真的更“干净”吗
URL 确实更干净（/user/123 vs /#user/123），但代价是必须处理服务端 fallback，且部分老环境（IE9 及以下）不支持。
如果你的项目要兼容 IE9，或者部署在无法修改服务端配置的静态空间里，hash 仍是更稳妥的选择——location.hash 改变不发请求，hashchange 事件也广泛支持。
-
history.pushState()无法跨域，location.hash可以（但通常没必要） - SEO 方面，现代搜索引擎基本都能抓取 History 路由，但需确保首屏 HTML 包含有意义的内容（不是纯空壳）
- 调试时注意：DevTools 的 Network 面板不会显示
pushState()的“请求”，容易误以为没生效
实际用起来，最难的不是调 API，而是让路由状态、UI 渲染、浏览器地址栏、服务端响应这四者始终对齐。稍有疏漏，就会出现“点后退没反应”“刷新白屏”“URL 对不上内容”这类问题。
