will-change 对 width/height/left 等属性无效，因其触发 Layout+Paint，而 will-change 仅支持 transform/opacity/scroll-position/contents；必须先将动画迁移到 transform 或 opacity 才能生效。
will-change 对复杂盒模型动画（如改 width、left、border-radius）基本无效，加了反而更卡——除非你先把动画逻辑迁移到 transform 或 opacity。
为什么直接给 width/height/left 加 will-change 没用
浏览器只响应 transform、opacity、scroll-position、contents 这四个值；其余声明（如 will-change: width）会被忽略或触发无效预分配。更关键的是：width、left 等属性变化必然触发 Layout + Paint，will-change 根本无法绕过这一步。Chrome DevTools Performance 面板里若看到主线程 Layout 占比高，说明问题在动画写法本身，不是渲染提示没加。
-
will-change: left在 Chrome/Safari 中被直接忽略，元素仍走 Layout → Paint → Composite 全流程 - 混用
left和transform会让浏览器降级回 Layout 动画，will-change完全失效 - 静态写死
.item { will-change: width; }会导致图层常驻，GPU 内存持续上涨
必须先重构动画到 transform/opacity 才能生效
所谓“优化”，本质是把视觉效果从 Layout/Paint 路径，挪到纯 Composite 路径。这不是锦上添花，而是硬性前提：
- 位移：用
transform: translateX(100px)替代left: 100px - 缩放：用
transform: scale(1.2)替代改width/height - 圆角呼吸感：用
transform: scale()+overflow: hidden模拟，或 SVG mask - 内边距动效：用
transform: translateY()移动子内容，外层尺寸固定 - 边框粗细变化：用
box-shadow切换预设值，或transform: scale()模拟
动态设置 will-change: transform 的正确时机
重构完动画后，will-change 才是最后一道“启动加速器”，但必须 JS 控制生命周期，不能写死在 CSS 里：
立即学习“前端免费学习笔记（深入）”；
- 动画开始前 1 帧设置：
element.style.willChange = 'transform'; - 监听
transitionend或animationend，不用setTimeout猜时长 - 清除必须用双
requestAnimationFrame：requestAnimationFrame(() => { requestAnimationFrame(() => { element.style.willChange = 'auto'; }); }); - 别在父容器和子元素同时设 —— 图层嵌套会放大开销
- 移动端尤其敏感：iOS Safari 图层管理保守，常驻图层易白屏；中低端安卓机图层超 5～8 个就纹理上传阻塞
验证是否真起效，别信“看起来顺”
打开 Chrome DevTools → Layers 面板，确认图层数量合理（比如一屏列表项仅 1～2 个升层）；再进 Performance 面板录制动画，重点看 Composite 阶段是否滞后、主线程 Layout/Paint 是否归零。如果主线程依然满载，will-change 一个字都别加——那是代码结构或 JS 阻塞的问题，不是渲染提示不到位。
