移动端css动画卡顿主因是使用top/left/width/height等触发重排的属性，应统一用transform和opacity实现gpu加速，避免will-change滥用，并通过chrome devtools验证合成层是否真实创建。
移动端CSS动画卡顿，90%不是因为没开GPU加速，而是用了top、left、width、height这类属性——它们一动就触发重排，主线程直接堵死。
为什么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应用前那一帧（不是提前写死），并同步清除
- JS中设置：
el.style.willChange = 'transform'，监听animationend后立刻设el.style.willChange = 'auto' - iOS Safari对≤16ms动画可能不触发该事件，务必加兜底：
setTimeout(() => el.style.willChange = 'auto', duration + 100) - 绝对不要对列表项批量加，比如
.list-item { will-change: transform; }
验证GPU加速是否真实启用
写了will-change、用了transform，不代表真加速。必须用Chrome DevTools验证：
- 打开
Rendering面板 → 勾选Layer borders：看到细橙色边框才表示独立合成层已创建 - 勾选
Paint flashing：动画期间大面积绿色闪动 = 频繁重绘，说明没走GPU - 注意：某些安卓机型在父容器设了
overflow: hidden时，子元素transform会强制回退到CPU渲染 - 慎用
transform: translate3d(0, 0, 0)：虽能强制升层，但功耗和内存占用更高；优先用translateZ(0)或动态will-change
最易被忽略的一点：动画持续时间短（比如0.15s）时，很多浏览器根本来不及升层，will-change和translateZ(0)都无效——这种场景直接用transform + opacity + linear缓动更稳。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
