will-change对原生overflow局部滚动无效，仅适用于JS或CSS动画驱动transform位移的容器，如横向轮播.track、下拉刷新.header、虚拟滚动中动态位移的item；滥用会导致图层爆炸、GPU内存飙升及iOS白屏。
will-change 对局部滚动区域基本无效，加了反而更卡——它只对“用 transform 模拟滚动”的容器起作用，原生 overflow 容器不该加。
哪些局部滚动容器适合加 will-change: transform
只有那些**不用 overflow、靠 JS 或 CSS 动画驱动位移**的滚动区域才可能受益。比如：
- 横向轮播组件中实际做 translateX 位移的
.carousel-track - 下拉刷新时做 translateY 动画的
.refresh-header - 虚拟滚动中正在进出视口、且被 JS 动态加了
transform: translateY()的 item（需配合 class 切换）
而像 .scroll-container { overflow-y: auto; height: 300px; } 这种纯原生滚动，浏览器已内置合成优化，will-change: transform 不仅没加速效果，还可能干扰默认图层策略。
为什么给 .scroll-container 加 will-change 反而掉帧
常见错误是把 will-change: transform 写在局部滚动容器上，却没配真实 transform 变化。结果是：
立即学习“前端免费学习笔记（深入）”；
- 浏览器提前创建独立图层，但元素实际没动 → 图层空转，白占 GPU 内存
- 中低端安卓机上，图层数超 5～8 个后，纹理上传开始阻塞，滚动帧率从 60fps 掉到 20fps
- iOS Safari 更敏感，偶发白屏或合成器中断
- 如果容器有
border-radius或overflow: hidden，还会强制回退软件渲染，will-change彻底失效
验证是否真生效？打开 Chrome DevTools → Layers 面板，看是否多出对应图层，且数量可控。
真正该做的三件事，比加 will-change 重要得多
90% 的局部滚动卡顿根源不在渲染层，而在主线程或布局抖动：
- 滚动监听必须带
{ passive: true }：否则 iOS Safari 可能禁用惯性滚动 - 绝对禁止在
scroll回调里读取scrollTop、getBoundingClientRect()或写element.style.xxx—— 这会强制同步回流 - 图片必须设宽高 +
loading="lazy"；长列表优先用react-window或vue-virtual-scroller，而不是靠will-change硬撑
动态加/删 will-change 的时机也极关键：只在用户 touchstart 后加，动画结束（监听 transitionend）立刻清，漏掉清理就是线上最常被忽略的内存隐患。
