transform 和 opacity 动画更流畅是因为它们能触发 gpu 合成层，避开主线程的重排与重绘；其他属性如 width、left、background-color 会强制触发 layout 或 paint 导致卡顿。
为什么 transform 和 opacity 动画在移动端更流畅
因为只有 transform（平移、旋转、缩放）和 opacity 这两类属性能触发浏览器的合成层（compositor layer），让动画交由 GPU 处理，避开主线程重排（reflow）和重绘（repaint）。其他属性如 width、height、left、top、background-color 都会强制触发 Layout 或 Paint，卡顿明显。
实操建议：
- 把位移动画从
left: 10px改成transform: translateX(10px) - 隐藏/显示切换优先用
opacity: 0+pointer-events: none，而不是display: none或visibility: hidden - 避免在动画中同时修改
transform和box-shadow—— 后者会破坏图层合并，导致频繁合成
如何主动触发 GPU 加速但不滥用 will-change
will-change 是个提示，不是魔法。盲目加 will-change: transform 可能提前创建过多合成层，反而增加内存开销和上下文切换成本，尤其在低端 Android 设备上更明显。
正确做法：
立即学习“前端免费学习笔记（深入）”；
- 只对「真正正在动画」或「即将开始动画」的元素动态添加
will-change，动画结束立即移除（可用 JavaScript 控制 class 切换） - 优先用
transform: translateZ(0)或transform: translate3d(0, 0, 0)作为轻量级触发方式，兼容性更好，副作用更小 - 避免在列表项（如
.item）上批量写will-change: transform—— 浏览器可能为每个都建独立层，OOM 风险上升
移动端 CSS 动画卡顿的常见误操作
很多“优化”实际适得其反，尤其在 iOS Safari 和安卓 Chrome 80+ 上表现突出：
- 用
@keyframes动画控制font-size或border-radius：这两项都会触发 Layout，且无法硬件加速 - 动画元素父容器设置了
overflow: hidden但子元素有transform：某些安卓机型会强制回退到 CPU 渲染 - 动画时长设为
0.3s却配了ease-in-out—— 缓动曲线在首尾帧计算压力大，低端机易掉帧；改用linear或cubic-bezier(0.34, 1.56, 0.64, 1)（简化版 ease）更稳 - 同一元素同时跑多个
@keyframes（比如位移 + 旋转 + 透明度）：确保它们都在一个animation声明里，别拆成多个规则，否则浏览器难合并图层
验证是否真走 GPU 渲染的快速方法
不能只看“看起来顺”，得看真实渲染路径：
- Chrome DevTools → Rendering 面板 → 勾选
Paint flashing：动画期间大面积绿色闪动 = 频繁重绘，说明没走 GPU - 同面板勾选
Layer borders：看到细黄边框围绕动画元素 = 成功提升为合成层；若边框闪烁或消失，说明图层被反复升降 - iOS Safari 没有内置渲染调试，可临时加
outline: 1px solid red在动画元素上，如果 outline 跟随卡顿，则大概率还在主线程渲染
真正影响体验的，往往不是“有没有加 transform”，而是“有没有意外触发 Layout”和“图层是否稳定”。多看 Layers 面板，少信直觉。
