只需在html元素上设置scroll-behavior: smooth即可实现全局锚点平滑滚动，无需JS；必须作用于html而非body或通配符，且需排查!important覆盖、目标元素可见性及Shadow DOM隔离等问题。
如何用 scroll-behavior 实现全局锚点平滑滚动
直接加一行 CSS 就能生效，不需要 JS。关键在根元素（html）上设置 scroll-behavior: smooth，浏览器会自动接管所有原生锚点跳转（比如点击 <a href="#section1"></a>）的滚动行为。
常见错误是只给 body 设，但实际必须作用于 html 元素——因为滚动容器是视口根，不是 body。另外，这个属性不继承，不能写在 * { scroll-behavior: smooth } 里。
-
html { scroll-behavior: smooth; }是唯一可靠写法 - 仅对 CSS 定义的锚点（
id匹配）和history.pushState后的hashchange生效，对 JS 手动调用element.scrollIntoView()无效（除非显式传{ behavior: 'smooth' }） - 部分旧版 Safari（≤15.4）对
html上的该属性支持不稳定，可降级为监听hashchange+ JS 补偿
为什么 scroll-behavior 在某些页面没反应
最常踩的坑是页面存在「强制重置滚动行为」的 CSS，比如第三方 UI 库或重置样式表里写了 html, body { scroll-behavior: auto !important; }，直接覆盖了你的设置。
另一个典型场景：使用了 position: fixed 或 overflow: hidden 的全屏布局框架（如某些 SPA 路由容器），导致锚点目标元素不在默认文档流中，浏览器无法计算滚动位置。
立即学习“前端免费学习笔记（深入）”；
- 用浏览器开发者工具检查
html元素的 computed 样式，确认scroll-behavior确实是smooth且未被!important覆盖 - 确保目标
id元素存在于 DOM 中，且没有被display: none、visibility: hidden或父级overflow: hidden遮挡 - 如果用了 Web Components 或 Shadow DOM，
scroll-behavior不穿透影子边界，需在 shadow root 内单独设置
兼容性与降级方案怎么选
Chrome 61+、Firefox 36+、Edge 79+、Safari 15.4+ 原生支持 scroll-behavior。低于这些版本（尤其是 Safari ≤15.3）需要 JS 介入。
不推荐全量引入第三方滚动库（如 smooth-scroll），多数情况只需几行代码补全。
- 检测支持：
if ('scrollBehavior' in document.documentElement.style) { /* 原生可用 */ } - 降级时优先拦截
hashchange事件，而不是点击事件——避免干扰按钮、表单等非锚点交互 - 用
document.getElementById(hash.slice(1))获取目标元素，再调用.scrollIntoView({ behavior: 'smooth' })，注意处理null情况（比如 hash 不存在）
平滑滚动影响性能吗？要不要节流
原生 scroll-behavior 由浏览器底层实现，不触发重排，也没有 JS 回调开销，性能几乎无感。JS 降级方案中，scrollIntoView 本身也是原生 API，只要不频繁手动调用（比如监听 scroll 事件去修正位置），完全不用节流。
真正要小心的是：在单页应用中，路由变化后立即执行 scrollIntoView，可能因组件异步渲染导致目标元素尚未挂载。这时不是性能问题，而是时机问题。
- 不要在
useEffect或mounted里立刻滚动，改用requestIdleCallback或setTimeout(..., 0)延迟一帧 - 若目标元素是动态加载的（如图片、懒加载区块），需等其
offsetTop可读后再滚动，否则会滚到错误位置 - 移动端 iOS Safari 对
behavior: 'smooth'的动画帧率控制较弱，偶尔有卡顿，但属于系统级限制，无法通过代码优化
CSS 平滑滚动看着简单，但真实项目里最容易被忽略的是「目标元素是否真的就位」——ID 拼错、渲染延迟、Shadow DOM 隔离、甚至 SSR 和 CSR 的 DOM 差异，都可能让那一行 scroll-behavior 彻底失效。
