scroll-behavior: smooth 本身不解决定位元素滚动卡顿，真正起效的是通过 will-change: scroll-position（或 fallback transform）让滚动容器提前进入 GPU 合成层，且需避免滥用导致层爆炸或重绘异常。
scroll-behavior: smooth 本身不解决定位元素滚动卡顿
用 scroll-behavior: smooth 给容器加丝滑滚动，对通过 document.getElementById().scrollIntoView() 或锚点跳转确实有效，但一旦元素是 position: fixed、absolute 或受 transform 影响（比如被父级 transform: translateZ(0) 包裹），浏览器可能跳过合成层优化，导致滚动帧率掉到 30fps 甚至卡顿。
真正起作用的是让滚动目标元素或其祖先提前进入 GPU 合成层 —— 这才是 will-change 的实际职责。
-
will-change不是“让滚动变滑”，而是“告诉浏览器：这个元素接下来很可能要动，提前备好图层” - 它只对后续的动画/滚动有预热效果，对已开始的滚动无效
- 滥用会导致内存占用升高、页面初始化变慢，尤其在低端安卓 WebView 中容易触发渲染崩溃
给谁加 will-change 才真正影响滚动性能
不是给滚动容器（比如 .scroll-container）加，也不是给目标元素（比如 #section-3）加，而是给「滚动过程中持续参与变换」的那个元素加。常见误操作是加在目标锚点上，但锚点本身不动，动的是视口或容器的 scroll offset。
- 如果用
scrollTo({ behavior: 'smooth' })滚动整个页面 → 应该加在body或html上（但需谨慎，见下条） - 如果滚动的是某个
overflow: auto的局部容器 → 加在该容器上，如.list-wrapper - 如果容器内有 sticky 导航栏，且它随滚动频繁重绘 → 可单独给
.sticky-header加will-change: transform
示例：
.scroll-area {
overflow-y: auto;
scroll-behavior: smooth;
will-change: scroll-position; /* ✅ 正确：现代浏览器识别该值 */
}注意：will-change: scroll-position 是专为滚动优化的取值，比 transform 更精准，但仅 Chromium 115+ 和 Safari 17.4+ 支持；旧版本 fallback 用 transform 即可。
will-change 引发的常见滚动异常
加了 will-change 却更卡？大概率是触发了层爆炸或 repaint 频繁。典型现象包括：滚动时文字模糊、输入框失焦、fixed 元素抖动、iOS Safari 回弹失效。
立即学习“前端免费学习笔记（深入）”；
- 不要在全局样式里写
* { will-change: transform }—— 这会让所有元素进合成层，内存翻倍 - 避免和
transform: translateZ(0)同时存在，二者叠加可能让浏览器重复创建图层 - 动态添加
will-change后没及时移除（比如滚动结束 300ms 后）→ 图层长期驻留，拖慢后续动画 - 在 React/Vue 中用 class 切换控制
will-change时，确保 DOM 更新已 commit，否则样式可能不生效
替代方案比盲目加 will-change 更可靠
很多所谓“丝滑滚动问题”，根源不在合成层缺失，而在 JS 干扰滚动主线程。比如监听 scroll 事件做计算、频繁读取 offsetTop、或在滚动中触发动画重排。
- 优先用
getBoundingClientRect()替代offsetTop+ 父级遍历，减少 layout thrashing - 滚动监听务必用
passive: true，并配合requestIdleCallback做非关键计算 - 定位跳转前，先用
el.scrollIntoView({ block: 'start', inline: 'nearest' })关闭平滑，再手动scrollTo控制节奏，比全靠 CSS 更可控 - 真要压榨性能：把滚动容器设为
contain: layout paint，能显著减少样式计算范围
复杂点在于，will-change 的效果高度依赖浏览器版本、GPU 驱动、甚至系统电源模式 —— 同一段代码，在 MacBook 插电时流畅，电池模式下就掉帧。别把它当开关，当成性能调优的最后一步来验证。
