移动端CSS动画卡顿主因是使用top/left/width/height触发重排，应仅用transform和opacity实现60fps；需避免混用非合成属性、合理动态设置will-change并用DevTools验证图层。
移动端 CSS 动画卡顿，90% 不是因为没开 GPU 加速，而是用了 top、left、width、height 这类属性——它们一动就触发重排，主线程直接堵死。真正能稳住 60fps 的，只有 transform 和 opacity。
为什么用 top/left 动画必卡
每次改 top 或 left，浏览器必须重新计算整个文档流的位置、尺寸、换行、文本布局……这个过程叫重排（reflow），全靠 CPU 干活。低端安卓机（尤其 Android 5–7 WebView）调度弱，一帧内反复重排，主线程瞬间卡死，手指滑动都“粘滞”。而 transform: translateX(100px) 只挪图层，GPU 合成线程直接处理，不碰布局也不重绘。
- 错：
transition: left 0.3s→ 整条过渡降级回 CPU 渲染 - 对：
transition: transform 0.3s→ 且只改transform，别混top或margin - 位移统一用
transform: translate(30px, 20px)，不是top/left组合 - 缩放用
transform: scale(0.9)，旋转用rotate(45deg)，别碰width/height
@keyframes 里只留 transform 和 opacity
浏览器不会报错，但只要关键帧里塞进一个非合成属性，整段动画就默默退回到 CPU 渲染。哪怕只是加了个 box-shadow 或 background-color，帧率也会掉下去。
- 安全组合：
@keyframes slide { from { transform: translateX(-100%); opacity: 0; } to { transform: translateX(0); opacity: 1; } } - 删掉所有
width、height、margin、filter、box-shadow - 文字颜色渐变别用
color动画，改用两层文字叠在一起，靠opacity切换显隐 - 关键帧尽量压缩：从
0% → 25% → 50% → 75% → 100%简化为0% → 100%，用cubic-bezier(0.34, 1.56, 0.64, 1)替代ease-in-out
will-change 是提示，不是开关
will-change: transform 是提示，不是指令；浏览器是否真建层、何时回收，由实现决定，不可控。静态写 .item { will-change: transform; } 等于给一屏 20 个列表项各占一块 GPU 内存，低端安卓机极易 OOM 卡死。
立即学习“前端免费学习笔记（深入）”；
- 只对「即将开始动画」的单个元素，在用户真实交互瞬间动态设置，动画一结束立刻清除
- 推荐用 class 控制：
.card.is-animating { will-change: transform; } - JS 添加时机：
element.addEventListener('touchstart', () => element.classList.add('is-animating')) - 移除必须监听
animationend（不是transitionend），并同步清空：element.addEventListener('animationend', () => element.classList.remove('is-animating')) - 若用 JS 动画（
requestAnimationFrame），第一帧设will-change，最后一帧清空
验证 GPU 加速是否真实生效
写了 will-change、用了 transform，不代表真加速。必须看底层行为：
- Chrome DevTools →
Cmd+Shift+P输入 “Rendering” → 勾选Layer borders - 看到细橙色边框 = 合成层已建立；没边框或边框太粗/太多 = 图层未启用或爆炸
- 同面板勾选
Paint flashing：动画期间大面积绿色闪动 = 频繁重绘，说明没走 GPU - 打开
Layers面板，确认layerCount是否异常升高（>50 层需警惕）
真正卡顿的地方，往往藏在你没检查的图层边界和重绘区域里，而不是代码里那行 will-change。
