移动端css动画卡顿主因是误用非合成属性：仅transform和opacity能稳住60fps，混入top/left等会触发重排致主线程堵塞；须避免transition:all、禁用js同步读取布局，并通过devtools layer borders验证绿色图层。
移动端 CSS3 动画卡顿，90% 不是因为没开 GPU 加速，而是开了但用错了属性、时机或方式——transform 和 opacity 是仅有的两个能稳住 60fps 的合成属性，混入其他任何属性都会整段降级回 CPU 渲染。
为什么 top/left 动画必卡
改 top 或 left 会强制触发重排（reflow），浏览器得在主线程里重新计算位置、尺寸、换行、文本流……低端安卓机（尤其 Android 5–7 WebView）一帧内反复重排，直接堵死主线程。实测一次重排耗时 3–8ms，远超 16.67ms 的帧间隔。
transform: translateX(100px) 完全不同：它只挪图层，由 GPU 合成线程处理，不碰布局、不重绘、不阻塞主线程。
- 错：
@keyframes slide { to { left: 200px; } }→ 整段动画降级回 CPU 渲染 - 对：
@keyframes slide { to { transform: translateX(200px); } }→ 真正走合成管线 - 别混用：同一动画里同时写
left和transform，浏览器会放弃硬件加速
transition 里只写 transform，别碰 all
transition: all 0.3s 是定时炸弹——哪怕 hover 时顺带改了 color 或 border，也会触发无谓重绘，整条过渡立刻掉帧。
- ✅ 正确写法：
transition: transform 0.3s cubic-bezier(0.25, 0.46, 0.45, 0.94); - ✅ 同时做位移+缩放：
transition: transform 0.3s;即可（transform是单一属性名） - ❌ 错误写法：
transition: left, transform 0.3s;—— 混入非合成属性等于放弃 GPU 加速 - ⚠️ 注意：
opacity动画也必须单独声明transition: opacity 0.3s;，不能和transform合并在一个transition声明里混写（除非你确定两者始终同步变化）
will-change 是提示，不是保险丝
静态写 .item { will-change: transform; } 等于给每个元素提前建 GPU 图层，在一屏 20 个列表项的场景下，低端安卓机极易 OOM 卡死。
- ✅ 加的时机：用户交互触发瞬间，比如
touchstart后、动画 class 应用前那一帧 - ✅ 推荐方式：
.card.is-animating { will-change: transform; }，用 JS 控制 class 切换 - ✅ 删的时机：监听
animationend（不是transitionend）后立刻清除；iOS Safari 对 ≤16ms 动画可能不触发该事件，务必加兜底：setTimeout(() => el.classList.remove('is-animating'), duration + 100) - ❌ 绝对不要写：
* { will-change: transform; }或批量加到列表项上
怎么确认 GPU 加速真起了作用
写了 transform、加了 will-change，不代表真加速。关键看浏览器是否真建了独立合成层：
- Chrome DevTools → Rendering 面板 → ✅ 勾选 “Layer Borders”：有绿色边框才是被提升的图层
- Layers 面板搜索目标元素：应单独显示为
GraphicsLayer，而非 “Shared with ancestor” - 没绿框？检查父容器是否设了
overflow: hidden或filter: blur(1px)—— 这些会抑制子元素提层 - 动画过程中禁用所有
getBoundingClientRect()、offsetHeight、getComputedStyle()—— 即使只调一次，也会强制同步 layout，直接破防
最容易被忽略的点是：JS 读取布局信息会悄悄破坏所有优化，哪怕 CSS 全写对了也救不回来；而图层验证必须手动打开 Layers 面板确认，不能靠“我以为开了”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
