will-change不是滚动性能开关，仅对JS或CSS transform驱动的模拟滚动有效，须动态设置并及时清除；原生overflow: scroll容器加了反而更卡，因其已内置合成优化，滥用会导致GPU图层爆炸、帧率骤降。
will-change 不是滚动性能开关，加了原生 overflow: scroll 容器反而更卡——它只对 JS 或 CSS transform 驱动的模拟滚动起作用，且必须动态设置、及时清除。
哪些滚动场景真需要 will-change: transform
只有元素本身在滚动过程中**真实、高频地执行 transform 变化**时，will-change 才可能生效。典型场景包括：
- JS 轮播组件中正在被
touchmove实时更新element.style.transform的.carousel-track - 虚拟滚动里正进出视口、且被 JS 动态加上
transform: translateY()的单个.item（需配合 class 切换） - 下拉刷新头区域做
transform: translateY()动画的.refresh-header - 侧边栏用 JS 拖拽控制
translateX()位移，而非纯 CSStransition
所有带 overflow-y: auto 的原生滚动容器（如 .scroll-container）都不该加——浏览器已内置合成优化，加了反而干扰默认策略。
will-change: transform 为什么一加就卡
常见错误是把 will-change: transform 写死在 CSS 里，或加给不该加的元素。后果直接体现在 GPU 图层管理上：
- 写在每个列表项（
.item）上 → 一屏常驻 20+ 个图层 → 中低端安卓机纹理上传阻塞，帧率从 60fps 掉到 20fps 以下 - 加在父容器（如
.list-container）但子项才是位移主体 → 信号发错对象，图层建得过大、空转耗资源 - 元素初始为
display: none或visibility: hidden→will-change根本不生效 - 容器带
border-radius或overflow: hidden→ 强制回退软件渲染，will-change彻底失效
Chrome DevTools 的 Layers 面板里若看到图层数长期 > 8，基本就是 will-change 滥用导致。
立即学习“前端免费学习笔记（深入）”；
怎么加才不翻车：动态生命周期必须闭环
静态声明等于长期占用 GPU 内存，必须用 JS 精确控制“预约”和“释放”两个时刻：
- 在交互开始前 1–2 帧设置：
element.style.willChange = 'transform'（例如touchstart阶段） - 动画结束后立刻清除：
element.addEventListener('transitionend', () => { element.style.willChange = 'auto'; }) - 推荐嵌套两层
requestAnimationFrame清除，确保绘制完成后再销毁图层，避免闪屏 - 绝不能对父容器和子元素同时设 —— 图层嵌套会指数级放大开销
如果只是用 transform: translateZ(0) 显式升层，比 will-change 更稳、兼容性更好，也无需 JS 管理生命周期。
真正卡顿的根源往往和 will-change 无关
90% 的移动端滚动卡顿来自主线程阻塞，不是渲染层没加速：
-
scroll回调没加{ passive: true }→ iOS Safari 可能直接禁用惯性滚动 - 在
scroll里读取scrollTop或getBoundingClientRect()→ 强制同步回流，一滚就掉帧 - 图片没设宽高 +
loading="lazy"→ 每张图加载都触发重排 - 长列表没用
react-window或vue-virtual-scroller→ DOM 节点数几千个，主线程永远忙不过来
漏掉 will-change 的清理步骤，是线上最常被忽略的内存泄漏点——它不报错，但图层持续驻留，越滚越卡。
