will-change 不是魔法属性，需在交互触发前一刻动态设置、动画结束后立即移除；仅对 transform 和 opacity 有效，滥用会导致图层爆炸、内存飙升和卡顿。
will-change 不是“开个开关就变流畅”的魔法属性，用错反而更卡。真正起效的前提是：只对即将变化的 transform 或 opacity 属性，在交互触发前一刻设置，并在动画结束后立刻移除。
为什么直接写 will-change: transform 会让安卓机更卡
浏览器看到 will-change: transform，会立即为该元素创建独立合成图层、分配 GPU 内存、预上传纹理——但若这个元素实际只动一次、或根本没动，所有开销都白费。尤其在列表项、轮播容器里批量加，极易引发图层爆炸（layer explosion），内存飙升，后续滚动/点击响应变慢，甚至触发 WebView 回收导致白屏。
常见错误现象：
- 页面刚加载就卡顿，哪怕还没触发任何动画
- 连续快速滑动后，动画突然掉帧或闪烁
- 低端安卓机上出现明显发热、耗电加快
怎么用 will-change 才真有用
它本质是个“预告信号”，不是常驻配置。关键在时机控制和作用域收敛：
立即学习“前端免费学习笔记（深入）”；
- 只在用户真实交互瞬间设置：比如监听
touchstart或mouseenter，JS 动态添加.is-animating类 - 动画结束必须立刻清除：监听
animationend或transitionend，同步移除 class 和will-change - 配合
animation-fill-mode: forwards防止动画最后一帧残留样式干扰移除逻辑 - 复杂交互动画（如侧滑菜单）可套一层
requestIdleCallback延迟移除，避免和主线程渲染争资源
transform 和 opacity 是唯一值得配 will-change 的属性
只有这两个属性能走合成线程（compositor thread），不触发布局（layout）和重绘（paint）。其他任何属性——left、top、width、height、background-position、rgba() 的 alpha 值——即使加了 will-change，也照样强制重排重绘，卡顿照旧。
实操建议：
- 位移动画一律转成
transform: translateX(10px)，别用left: 10px - 缩放/旋转统一用
scale(1.2)、rotate(45deg) - 透明度变化只用
opacity: 0.8，别碰rgba(0,0,0,0.8) - 需要“伪硬件加速”兜底时，优先用
backface-visibility: hidden，比乱加will-change更安全
先看 DevTools，再决定要不要加 will-change
很多所谓“卡顿”根本和 will-change 无关。打开 Chrome DevTools → Rendering → 勾选 “Paint flashing” 和 “FPS meter”，边操作边观察：
- 如果满屏绿色高亮（paint），说明问题在绘制：检查图片尺寸、
box-shadow层数、渐变复杂度 - 如果 Layers 面板里图层数量暴增且尺寸过大（比如整屏都成了一个图层），那就是
will-change滥用或transform未收敛导致 - 帧率曲线频繁跌破 45fps，但 paint 区域很小——这时才值得尝试精准的
will-change控制
真正容易被忽略的是：动画元素是否被 position: absolute 或 fixed 脱离文档流。否则，哪怕用了 transform，父容器仍可能因子元素位置变化而反复重排。
