location.hash跳转失败主因是目标元素未渲染或id不合法；需确保id唯一、纯ASCII，并在DOM挂载后操作，必要时用scrollIntoView补救；刷新丢hash应手动拼接URL而非reload；SPA中锚点跳转需兼顾路由与服务端fallback。
location.hash 跳转后页面不滚动到锚点
常见现象是：执行 location.hash = "#section2" 后，URL 变了，但页面没滚上去。原因通常是目标元素还没渲染完成，或元素 id 不存在/重复/含非法字符（如空格、中文未编码）。浏览器只认原生 id 属性，不认 name 或 class。
- 确保目标元素存在且
id="section2"唯一、纯 ASCII 字符（避免id="标题-1"） - 若在 Vue/React 等框架中动态渲染，需等 DOM 挂载后再设
hash，比如用nextTick或useEffect(() => {}, []) - 设完
hash后可加一行document.getElementById("section2")?.scrollIntoView({ behavior: "smooth" })强制滚动，绕过浏览器 hash 滚动的时机问题
reload 后 hash 丢失或跳转失效
location.reload() 默认不保留 hash，刷新后 URL 回到无锚点状态。这不是 bug，是规范行为。想保留并跳转，不能只靠 reload。
- 刷新前手动存
const savedHash = location.hash，再用location.href = location.origin + location.pathname + location.search + savedHash替代reload() - 不要用
location.assign(location.href)，它可能触发两次 history push（尤其在某些 iOS Safari 版本里） - 如果必须用
reload(true)（强制从服务器重载），那 hash 一定丢——此时只能服务端配合，在 URL 中把锚点转为 query 参数（如?ref=section2），前端 onload 时再解析并跳转
scrollIntoView 与原生 hash 滚动行为差异
直接改 hash 触发的是浏览器默认滚动，有平滑动画、自动聚焦、支持前进/后退；而 scrollIntoView 是 JS 主动控制，不进 history，也不触发 hashchange 事件。
- 需要监听锚点变化？必须用
window.addEventListener("hashchange", ...)，别指望scrollIntoView能触发它 - 想兼容老浏览器（如 IE），
scrollIntoView({ behavior: "smooth" })不支持，得降级为scrollIntoView()或用 polyfill - 滚动偏移不准？常见于有 fixed header 的页面，加
{ block: "start", inline: "nearest" }并配合 CSSscroll-margin-top（如#section2 { scroll-margin-top: 60px; }）更可靠
Vue/React 里用 router.push 做“带 reload 的锚点跳转”
单页应用里，router.push({ hash: "#section2" }) 不会刷新页面，只是更新路由状态。真要 reload + 锚点，本质是“换 URL 后刷新”，不是路由功能范畴。
立即学习“前端免费学习笔记（深入）”；
- Vue Router：别用
router.go(0)，它不重走导航守卫，也不清缓存；应构造完整 URL 后赋值给window.location - React Router v6：没有全局 reload API，
useNavigate不支持 reload，只能回退到原生window.location.replace(...) - 注意：SPA 刷新可能触发 404（服务端没配 fallback），这时锚点逻辑再对也没用——先确保服务端能正确返回 index.html
最易被忽略的一点：hash 是 URL 的一部分，但它的解析和滚动由浏览器原生控制，JS 只能“建议”或“补救”。任何试图用 JS 完全接管 hash 行为的做法，都会在边界场景（如页面加载中、iframe、iOS Safari 的后台标签）里掉链子。留一手原生机制兜底，比写一堆兼容逻辑更稳。
