移动端动画卡顿主因是使用top/left/width/height等触发重排的属性，而非gpu加速未开启；唯有transform和opacity能确保60fps流畅，因其仅走gpu合成线程，不触发布局与重绘。
移动端动画卡顿，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 应用前那一帧（不是提前写死），并同步清除
- JS 中设置：
el.style.willChange = 'transform'，监听transitionend后立刻设el.style.willChange = 'auto' - iOS Safari 对 ≤16ms 动画可能不触发该事件，务必加兜底：
setTimeout(() => el.style.willChange = 'auto', duration + 100) - 绝对不要对列表项批量加，比如
.list-item { will-change: transform; }
怎么确认 GPU 加速真生效了
写了 transform、加了 will-change，不代表真加速。关键看浏览器是否真建了独立合成层。
- Chrome DevTools → Rendering 面板 → 勾选 “Layer Borders”：有绿色边框的元素才是被提升的图层
- 没绿框？检查父容器是否设了
overflow: hidden或filter: blur(1px)—— 这些会抑制子元素提层 - 避免在动画元素上动态改
box-shadow或filter，它们可能破坏图层合并，退回到 CPU 渲染 - 动画过程中禁用所有
getBoundingClientRect()、offsetHeight、getComputedStyle()—— 即使只调一次，也会强制同步 layout，直接破防
真正顺滑的前提，不是“加了什么”，而是“全程只走合成阶段”：不触发布局、不触发重绘、不偷偷读取任何布局信息——这些细节一旦漏掉，再标准的 transform 也救不回。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
