移动端CSS动画卡顿主因是渲染优化不足，需精准使用will-change（交互前设置、动画后移除），优先用transform/opacity属性，避免布局重排，并通过DevTools定位真实瓶颈。
移动端 CSS 动画卡顿，往往不是动画本身写得有问题，而是浏览器没做好渲染优化。直接加 will-change 并不能“一键提速”，用错反而拖慢性能。关键在于精准告诉浏览器：哪些属性即将变化、何时变化、变化范围多大。
只对真正会变化的元素和属性设 will-change
滥用 will-change: transform 或 will-change: opacity 会让浏览器提前创建独立图层、分配 GPU 内存，但若元素根本不动，或只动一次就停，这些开销全白费，还可能引发重绘抖动。
- ✅ 正确做法：在用户交互触发前一刻设置，比如
button:hover或touchstart事件中通过 JS 添加 class - ❌ 错误做法：全局给所有动效元素写
will-change: transform，尤其在列表项或滚动容器里 - 示例：不要这样写：
.card { will-change: transform; }
推荐这样写：.card.is-animating { will-change: transform; }，JS 控制 class 的增删
优先用 transform 和 opacity 做动画
这两个属性能走合成（compositor）线程，不触发布局（layout）和绘制（paint），是移动端最安全的动画属性。哪怕不用 will-change，只要用对了，帧率也通常很稳。
- 避免用
left/top/width/height或background-position做频繁动画——它们会强制重排重绘 - 把位移、缩放、旋转统一转成
transform: translateX(10px) scale(0.9) - 透明度变化一律用
opacity，别用rgba()改 alpha 通道（后者仍属颜色重绘）
配合 will-change 的时机控制策略
will-change 是“预告”，不是“常驻许可”。设得太早、关得太晚，都会浪费资源。
立即学习“前端免费学习笔记（深入）”；
- JS 中建议：在
touchstart或mouseenter时添加will-change；动画结束（transitionend或animationend）后立刻移除 - 可用 CSS 自带的
animation-fill-mode: forwards配合 JS 移除逻辑，防止残留 - 复杂交互动画（如下拉刷新、侧滑菜单）可结合
requestIdleCallback延迟移除，避免主线程争抢
先测再加，用 DevTools 看真实瓶颈
很多卡顿其实跟 will-change 无关，比如图片未压缩、字体加载阻塞、JS 执行过长、过多阴影或模糊滤镜。
- 在 Chrome DevTools → Rendering → 勾选 “Paint flashing” 和 “FPS meter”，边操作边观察高亮区域和帧率曲线
- 打开 Layers 面板，确认是否真生成了预期的合成图层，有没有意外的图层爆炸（layer explosion）
- 如果发现大量绿色闪烁（paint），说明问题在绘制，
will-change解决不了，得优化图片、减少 box-shadow、用contain: paint隔离
