location.hash 是最轻量且兼容性最好的锚点跳转方案，仅改变 url 的 # 后部分，浏览器自动滚动至对应 id 元素，不触发页面重载；需确保目标元素有匹配 id，避免使用 name 属性。
用 location.hash 控制页面跳转时的锚点位置
页面跳转时想让某块区域（比如顶部导航、侧边栏）不刷新、不重载，本质不是“保持不变”，而是避免整页 reload —— 所以得用前端路由或 hash 跳转这类不触发页面卸载的方式。location.hash 是最轻量、兼容性最好、且无需框架支持的方案。
它只改变 URL 的 # 后部分，浏览器会自动滚动到对应 id 元素，且不重新请求 HTML。适合单页内导航、文档锚点、Tab 切换等场景。
- 必须确保目标元素有匹配的
id，例如跳转链接是#section2，那页面里就得有<div id="section2"> <li>不要用 <code>name属性替代id，现代浏览器对name锚点支持已弱化，尤其在严格模式下可能失效 -
hash改变会触发hashchange事件，可监听做联动处理，比如高亮当前 Tab - 调用后必须手动更新视图，
pushState自身不做任何 DOM 操作 - 需监听
popstate事件来响应浏览器后退/前进，否则历史栈变化但页面不动 - 服务端无需特殊配置，但直接访问带新路径的 URL 时，得确保返回的是完整 HTML（否则 404 或白屏）
- 路径可以是相对路径，但不能跨域；第二个参数（title）目前多数浏览器忽略，传空字符串即可
- 父页面无法直接读写 iframe 内 DOM，跨域时更受限，通信得靠
postMessage - SEO 不友好，搜索引擎通常不索引 iframe 内容
- 移动端手势（如滚动嵌套）、焦点管理、打印样式都更容易出问题
- 每个 iframe 是独立的渲染进程（Chrome 等），内存和性能开销比纯 JS 方案高得多
- 组件级生命周期（如
mounted、useEffect）会在每次切换时重新触发，不是“保持状态” - 如需保留状态（比如表单输入），得手动用
keep-alive（Vue）或useMemo+外部状态管理（React） - 路由懒加载（
defineAsyncComponent/lazy）不影响容器稳定性，只影响内部组件加载时机
用 history.pushState() 替代跳转，避免 DOM 重绘
如果需求不只是滚动，而是要动态替换部分内容（比如只更新 <main></main> 区域），location.hash 就不够用了。这时得用 history.pushState() 配合 JS 手动更新 DOM。
它不会导致页面刷新，URL 变化后用户可正常前进/后退，且状态可携带数据（如 { section: "user" }），比 hash 更语义化。
立即学习“前端免费学习笔记（深入）”；
iframe 嵌套：真·局部不刷新，但代价明显
如果必须让一块区域彻底与主页面解耦（比如嵌入第三方工具、隔离 CSS/JS 作用域），<iframe></iframe> 是唯一能保证“完全不变”的方式 —— 它的加载、渲染、脚本执行都独立于父页面。
但这是重武器，日常需求里容易误用。
SPA 框架里的 router-view 或 Outlet 是怎么工作的
Vue Router 的 <router-view></router-view>、React Router 的 <outlet></outlet>，底层其实还是基于 history.pushState() + 动态组件挂载。它们把“哪块该更新”这个逻辑封装好了，但原理没变：监听路由变化 → 匹配组件 → 替换指定容器内容。
关键点在于：这些容器本身（比如 <router-view></router-view> 标签所在位置）在首次渲染后就一直存在，只是内部子组件被销毁/重建。
真正难的不是“怎么让一处不变”，而是想清楚“不变”到底指什么：是不滚动？不重绘？不执行 JS？还是不丢失用户输入？不同目标对应完全不同技术选型，混用反而会让滚动错位、状态丢失、history 栈混乱 —— 这些问题往往在测试边缘路径时才暴露。
