移动端css动画卡顿主因是使用top/left/width/height触发重排，应统一用transform和opacity；will-change需动态设置并及时清除；需通过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卡死。
- 只对「即将开始动画」的单个元素，在用户真实交互瞬间动态设置，动画一结束立刻清除
- 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
真正容易被忽略的是：父容器的overflow: hidden、JS中读取offsetTop或getBoundingClientRect()这些操作，都会强制同步重排，直接打断渲染流水线——它们比will-change本身更隐蔽，也更致命。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
