真正起效的是给滚动容器加 will-change: scroll-position，而非定位元素或锚点目标；因滚动时持续变化的是容器的 scrollLeft/scrollTop，需提前为其触发 GPU 合成层。
滚动容器加 will-change: scroll-position 才真正起效
给定位元素（比如 position: fixed 的导航栏）或锚点目标加 will-change，对滚动性能基本没用——因为滚动时真正持续变化的是容器的 scrollLeft/scrollTop，不是目标元素本身。浏览器需要提前为「滚动位移」这个状态准备合成层，而不是为静止的锚点。
-
will-change: scroll-position是专为此场景设计的取值，Chromium 115+ 和 Safari 17.4+ 已支持，能精准触发滚动位置的 GPU 预合成 - 旧版浏览器 fallback 用
will-change: transform即可，别写will-change: top或will-change: left，这些值不被识别，还可能干扰渲染 - 如果整个页面滚动，该加在
html或body上；如果是局部容器（如.list-wrapper），就加在它自己身上
为什么给 position: absolute 元素加 will-change 反而更卡
绝对定位元素本身不随滚动位移变化，加 will-change 不仅无法加速滚动，还可能让浏览器误判图层关系：当它被包裹在有 transform 的父容器里时，会强制参与嵌套合成，导致重绘频率上升、文字模糊、fixed 元素抖动。
- 典型错误：在锚点跳转后给
#section-2加will-change: transform，但该元素没动画、也没滚动参与感 - 真正该加的，是那个“视觉上在动”的东西——比如滚动容器的视口、sticky 头部、或正在做平滑 scrollTo 的 wrapper
- 用 Chrome DevTools → Rendering → “Layer borders” 确认：加了之后是否真多出一层？别靠感觉，看实锤
滚动中动态设置 will-change 必须配清理逻辑
will-change 是临时提示，不是永久开关。写死在 CSS 里（如 .scroll-area { will-change: transform; }）等于长期占用图层资源，尤其在长列表页，内存和合成器压力会指数级上升。
- 正确做法是滚动开始前设：
container.style.willChange = 'scroll-position' - 滚动结束后两帧内清空：
requestAnimationFrame(() => requestAnimationFrame(() => container.style.willChange = 'auto')) - 避免在
scroll事件回调里反复 set/remove —— 节流不到位会导致状态堆积，图层创建/销毁开销反超收益
比 will-change 更关键的三件事，先查完再加
90% 的定位元素滚动掉帧，根因根本不在合成层——而在 JS 主线程被拖住或布局被意外触发。加 will-change 前，务必确认：
立即学习“前端免费学习笔记（深入）”；
- 是否在
scroll回调里读写了scrollTop、getBoundingClientRect()或修改了任何样式？哪怕一行也会强制同步回流 - 列表项内图片有没有设宽高？
img标签缺width/height会导致滚动中频繁 relayout - 是否用了虚拟滚动？真实 DOM 节点数上千时，
will-change再准也救不了主线程爆满
真正难的，是判断该不该加——不是所有卡顿都适合用 will-change 解决，它只对「GPU 合成阶段瓶颈」有效，对「JS 计算阻塞」或「布局抖动」完全无感。
