骨骼动画卡顿主因是JS计算压力或绘制开销，非合成层缺失；will-change对其基本无效，仅对纯CSS transform/opacity动画且满足自动提层前提时有效。
骨骼动画在移动端卡顿，基本不是 will-change 能解决的——它对 SVG <use>、Canvas 骨骼或 Lottie Web 这类基于 JS 驱动的动画无效；真正起作用的只有纯 CSS transform/opacity 动画，且必须满足“浏览器能自动提层”这个前提。
为什么给骨骼动画加 will-change 几乎没用
骨骼动画（如 Lottie、Rive、Spine WebGL 渲染器）本质是每帧通过 JS 计算大量节点坐标，再批量写入 transform 或 Canvas 绘制。浏览器无法预判这些动态值，will-change: transform 的静态提示对 runtime 生成的 transform 毫无意义。
-
will-change只在元素样式即将被 CSS transition / animation 触发变化时生效，不是 JSelement.style.transform = '...'的加速开关 - Lottie 官方明确不推荐加
will-change，实测反而因图层常驻导致内存上涨、滚动卡顿 - SVG 骨骼若用
<animateTransform>，属于 SMIL 动画，现代浏览器已弃用且不支持will-change
真正该做的：绕过 will-change，直击渲染瓶颈
移动端骨骼动画卡顿，90% 来自 JS 执行压力或绘制开销，不是合成层缺失。优先检查并调整以下几处：
- 用 Chrome DevTools → Performance 面板录制动画，确认主线程是否长期 > 16ms（说明 JS 计算超时），而非 Composite 阶段延迟
- Lottie 实例启用
renderer: 'canvas'替代'svg'，尤其在 Android WebView 中 canvas 性能更稳 - 设置
lottie.loadAnimation({ ... , rendererSettings: { preserveAspectRatio: 'xMidYMid slice' } })避免缩放重绘 - 对非关键骨骼（如飘带、粒子）降低
subframe精度或设speed: 0.5降频渲染
极少数可加 will-change 的边界场景
仅当你的“骨骼动画”其实是用 CSS @keyframes + 大量 transform 类名切换模拟（比如手写 20 个关节的 rotate/translate），且已确认首帧耗时 > 16ms、Layers 面板里该元素没绿色边框时，才考虑动态加：
立即学习“前端免费学习笔记（深入）”；
- 在播放开始前一帧设：
el.style.willChange = 'transform'; - 在最后一帧用双
requestAnimationFrame清除：requestAnimationFrame(() => { requestAnimationFrame(() => { el.style.willChange = 'auto'; }); }); - 绝对不要写
.joint { will-change: transform; }这类全局 CSS —— 一屏 15 个关节 = 15 个常驻图层，中低端机直接掉帧
真正决定骨骼动画是否流畅的，从来不是那一行 will-change，而是 JS 计算是否精简、Canvas 是否复用、DOM 是否隔离、以及有没有在动画中读取 offsetHeight 这类强制 layout 的 API。加了 will-change 却没关掉 console.log 或没做 canvas clearRect 裁剪，帧率照样崩。
