will-change对移动端复杂动效基本无效，除非动画已完全基于transform和opacity；盲目添加会导致图层爆炸、内存上涨、滚动卡顿，主因是JS超时或CSS重排/重绘。
will-change 对移动端复杂动效基本无效，除非你已把动画逻辑彻底迁移到 transform 和 opacity 上；盲目添加反而导致图层爆炸、内存上涨、滚动卡顿。
为什么加了 will-change 还是卡
移动端卡顿主因从来不是“没开硬件加速”，而是 JS 计算超时或 CSS 触发重排/重绘。骨骼动画（Lottie/Rive）、Canvas 动画、SVG <use>、甚至用 left/top 实现的位移动画，加 will-change: transform 都白搭——浏览器根本没法预判 runtime 生成的值，也不会为这些路径创建合成层。
- 错误现象：
will-change: transform写在 CSS 里，Layers 面板里看不到该元素，Reason字段为空 - 真实瓶颈：Performance 面板显示主线程持续 >16ms，说明卡在 JS 执行或 Layout/Paint 阶段
- 典型误用：给
.card全局声明will-change: transform，一屏 20 个卡片 = 20 个常驻图层，Android 中低端机直接掉帧
哪些值真能触发合成层
只有极少数属性变更时，will-change 才可能让浏览器提前升层并走 GPU 合成路径：
-
transform（含translateX、scale、rotateZ）——最可靠，全平台支持 -
opacity——必须有明显变化（如1 → 0），微调（0.99 → 1）通常不触发 -
scroll-position——Chrome/Firefox 支持有限，iOS Safari 完全不支持，慎用 -
contents——仅用于will-change: contents提示子树将整体替换，极少场景适用 - 其他全无效：
left、top、width、height、background-color、border-radius等加了不仅没用，还会干扰后续真实动画的分层时机
必须动态设置 + 双 requestAnimationFrame 清除
静态写死在 CSS 里等于长期占用 GPU 内存，现代浏览器（Chrome 98+、Safari 15.4+）已默认对 transform/opacity 动画自动提层，静态声明无额外收益，还易引发 OOM。
立即学习“前端免费学习笔记（深入）”；
- 正确时机：动画开始前 1 帧设
element.style.willChange = 'transform, opacity' - 清除必须用双
requestAnimationFrame，确保绘制完成后再销毁图层：element.style.willChange = 'transform'; requestAnimationFrame(() => { requestAnimationFrame(() => { element.style.willChange = 'auto'; }); }); - 监听
transitionend或animationend触发清理，别依赖mouseleave或定时器——容易漏掉或过早清除 - 绝对不要写
.joint { will-change: transform; }这类全局规则，关节多、列表长、滚动快的场景下，图层数会失控
真正该优先做的三件事
优化动效流畅度，will-change 是最后一道微调，不是救命稻草。先做这三步，90% 的卡顿就解决了：
- 用 Chrome DevTools → Performance 录制动画，确认瓶颈在主线程（JS/Layout/Paint）还是合成线程（Composite）
- 把所有盒模型动画（
width、height、border-radius、margin）全部迁移到transform模拟：缩放用scale()，圆角呼吸感用overflow: hidden+ 子元素位移，边框粗细用box-shadow替代 - 对 JS 驱动的动效（如 Lottie），启用
renderer: 'canvas'、关闭非关键骨骼、降低subframe精度，比加will-change有效十倍
真正起作用的永远不是「提示浏览器我要动了」，而是「我动的方式，刚好能让浏览器只合成、不重排不重绘」。will-change 只认这个前提，不认愿望。
