will-change 对滚动性能基本没用，除非用错对象；它只提示浏览器某可滚动容器的 scrollLeft/scrollTop 将变化，且仅在块级容器、有尺寸约束、用户直接触发滚动、无破坏样式时生效。
will-change 对滚动性能基本没用，除非你用错了对象——它不优化页面滚动，只提示浏览器“某个可滚动容器的 scrollLeft 或 scrollTop 要变了”。
will-change: scroll-position 只对特定容器生效
这个值不是“让滚动变快”的通用开关，它只在满足全部以下条件时才起作用：
- 元素是块级容器，且设置了
overflow: auto或overflow: scroll - 有明确的尺寸约束，比如
height: 400px或max-height: 300px - 滚动由用户直接触发（不是 JS 模拟的 transform 位移）
- 没有
border-radius、overflow: hidden或filter等会破坏滚动上下文的样式
典型有效场景：.chat-log { height: 500px; overflow-y: auto; }；无效场景：body、html、position: fixed 全屏弹层、虚拟滚动列表的外层 wrapper。
给 body 或 fixed 元素加 will-change: scroll-position 反而更卡
大面积定位元素（如导航栏、侧边栏、浮层）本身不滚动，只是随视口重绘位置。此时加 will-change: scroll-position 属于错配，后果包括：
立即学习“前端免费学习笔记（深入）”；
- 中低端安卓机图层数超 6～7 个后，纹理上传阻塞，
scroll事件回调延迟升高 - iOS Safari 可能直接忽略该提示，或触发合成器中断，出现瞬时白屏
- 若该元素还带
box-shadow或渐变背景，浏览器可能强制回退到软件渲染
真正拖慢滚动的，90% 是主线程被滚动监听阻塞，而不是渲染层问题。
比 will-change 更关键的三件事
滚动卡顿优先检查并修复这些：
- 滚动监听必须传
{ passive: true }：window.addEventListener('scroll', handler, { passive: true }); - 禁止在
scroll回调里读取element.scrollTop、getBoundingClientRect()或写style.top—— 这会强制同步回流 - 用
transform: translateY()替代top更新定位，再配合动态添加will-change: transform（仅动画触发时加，结束立刻设为auto）
记住：will-change 不是写死在 CSS 里的长期配置，而是一个需要精确控制生命周期的临时提示——加得早、去得晚，都等于没加。
