使用pushState/replaceState无刷新更新URL锚点本质是操作浏览器历史栈，需监听popstate而非hashchange事件，手动实现滚动定位，并注意服务端对history模式的fallback配置。
直接用 history.pushState() 或 history.replaceState()
无刷新更新 URL 锚点（比如从 #home 变成 #contact），本质不是操作锚点本身，而是操作浏览器历史栈——location.hash 的变化会触发页面跳转，而 pushState 和 replaceState 才是真正“无刷新”且可控的方式。
注意：location.hash = 'contact' 看似简单，但它会触发 hashchange 事件、滚动到对应元素（如果存在），且在某些场景下仍可能造成意外重绘或焦点跳变；更稳妥的做法是绕过 hash，用 pushState 模拟锚点语义。
-
history.pushState({ section: 'contact' }, '', '#contact')：新增一条历史记录，用户可点击后退回到上一状态 -
history.replaceState({ section: 'contact' }, '', '#contact')：替换当前历史记录，不增加新条目 - 两个方法的第三个参数必须是以
#开头的字符串，否则会触发跨域或协议错误 - 第一个参数是 state 对象，用于
popstate事件中恢复上下文，不能为空或null（Safari 旧版会报错）
监听 popstate 而不是 hashchange
如果你用了 pushState 更新 URL，就别再依赖 hashchange——它不会被触发。必须监听 popstate 事件来响应浏览器前进/后退。
常见错误是只绑了 hashchange，结果用户点返回按钮时页面没反应，还以为逻辑没生效。
立即学习“前端免费学习笔记（深入）”；
-
window.addEventListener('popstate', e => { console.log(e.state?.section) })——e.state就是之前传入pushState的第一个参数 -
popstate在页面首次加载时也可能触发（取决于 history 状态），建议加个 guard 判断是否为真实导航行为 - 不要在
popstate处理函数里再调用pushState，否则容易陷入循环（比如滚动定位后又触发一次状态更新）
滚动定位要手动做，浏览器不会自动跳转
用 pushState 改 URL 不会触发页面滚动，这是和原生 location.hash 最大区别——你得自己控制滚动行为。
否则用户点导航菜单更新 URL 后，页面静止不动，体验上就像“没反应”。
- 用
document.getElementById('contact').scrollIntoView({ behavior: 'smooth' })实现平滑滚动 - 注意目标元素是否存在：先
const el = document.getElementById('contact')，再判空，避免scrollIntoView报错 - 如果用 class 或 data 属性定位（比如
[data-section="contact"]），记得用document.querySelector()替代getElementById - 移动端 Safari 对
scrollIntoView({ behavior: 'smooth' })支持较晚（iOS 15.4+），降级方案可用el.scrollIntoView()或window.scrollTo()
pushState 在单页应用路由中的典型陷阱
很多开发者把 pushState 当成“轻量路由”，但忽略服务端配置，导致刷新页面 404。
这不是前端能解决的问题：URL 是 /app/#contact 还是 /app/contact 决定了是否需要服务端支持。
- 如果 URL 形如
/app/#contact：纯前端可行，服务端只需始终返回 index.html - 如果 URL 形如
/app/contact（无#）：必须配置服务端将所有路径 fallback 到 index.html，否则刷新即 404 - Vue Router / React Router 的
history模式就是走后者，而hash模式本质还是靠hashchange - 调试时用浏览器地址栏手动输入
/app/contact刷新一下，立刻暴露服务端问题
锚点更新看着简单，真正落地时最常卡在滚动不同步、后退失效、或者刷新崩掉——核心不是代码长短，而是对 history API 和浏览器导航机制的理解是否到位。
