history.pushstate(state, title, url) 可在不刷新页面下修改 url，需传入可序列化 state 对象、忽略的 title（常为空字符串）、同源的相对或绝对 url；必须监听 popstate 事件响应导航，并配置服务端 fallback 防止直接访问 404。
pushState 修改 URL 的基本调用方式
直接调用 history.pushState() 就能改地址栏路径，不触发页面刷新或重新加载。它接收三个参数：状态对象（可为 null）、页面标题（多数浏览器忽略）、目标 URL（必须同源）。
常见错误是传入跨域 URL 或相对路径写错，导致抛出 SecurityError 或静默失败。
- 第三个参数必须是同源的相对路径（如
"./search?q=js"）或绝对路径（如"/profile/123"），不能是完整 URL（"https://example.com/..."） - 标题参数实际很少起作用，传空字符串
""或null更稳妥 - 状态对象建议至少包含一个标识字段（如
{ page: "detail", id: 123 }），后续 popstate 事件里会用到
pushState 后浏览器前进/后退失效？别忘了监听 popstate
pushState 只改 URL 和历史记录，不会自动触发路由逻辑。用户点后退按钮时，URL 变了，但页面内容没变——这是最常被忽略的一环。
必须手动监听 popstate 事件，并根据 event.state 更新视图：
window.addEventListener('popstate', (event) => {
if (event.state?.page === 'detail') {
renderDetailPage(event.state.id);
} else if (event.state?.page === 'list') {
renderListPage();
}
});
- 首次加载页面时，
popstate不会触发，需在 JS 初始化时主动读取window.location.pathname做一次渲染 -
event.state是pushState第一个参数的副本，不是引用，修改它无效 - 服务端仍需配置 fallback（如 Nginx 返回 index.html），否则用户直接访问
/detail/456会 404
pushState 修改 URL 后 SEO 和相对资源路径会受影响吗
URL 改变本身不影响 SEO，但搜索引擎爬虫通常不执行 JS，也不会触发 pushState，所以纯前端路由页的内容对 SEO 不友好。这不是 pushState 的问题，而是单页应用架构的固有限制。
更实际的问题是相对路径解析：CSS、图片、API 请求里的相对 URL 仍以原始 HTML 加载路径为基准，不会随 pushState 改变而重算。例如初始加载自 /，之后 push 到 /admin/users，src="./logo.png" 依然请求 /logo.png，不是 /admin/logo.png。
- 所有静态资源路径建议用绝对路径（
/static/logo.png）或根相对路径（/logo.png） - API 请求也推荐用绝对路径（
/api/users），避免因当前 URL 深度不同导致请求错位 - 不要依赖
<base href>动态改写，它会影响整个文档，且无法在 pushState 后安全更新
replaceState 和 pushState 的关键区别在哪
history.replaceState() 行为和 pushState() 几乎一样，唯一区别是它不新增历史记录条目，而是替换当前这一条。
典型使用场景是初始化页面时“修正” URL：比如用户访问了带 hash 的旧链接 /#user/789，你想把它干净地替换成 /user/789，又不想让用户多一次后退操作，就用 replaceState。
- 两者参数完全一致，只是语义不同
- 误用
pushState替代初始化修正，会导致用户按一次后退回到空白或错误页（比如/#user/789） - 调试时注意 DevTools 的 History 面板：replaceState 不增加条目，pushState 会
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
