掉帧主因是动画触发重排或重绘，应仅用transform/opacity属性，避免top/left、box-shadow、filter等非合成属性，并动态添加/清理translate3d(0,0,0)或will-change以确保gpu加速。
掉帧不是因为手机“太老”，而是动画悄悄触发了重排（reflow）或重绘（repaint），把本该由 GPU 处理的合成任务，硬塞给了 CPU——而低端安卓机（尤其是 Android 5–7 WebView）的 CPU 根本扛不住每帧都算布局、画阴影、糊模糊。
为什么 top/left 动画必卡
改 top 或 left 会强制触发重排，浏览器得在主线程里重新计算位置、尺寸、换行、文本流……这个过程 CPU 全包。实测一次重排耗时 3–8ms，远超 16.67ms 的 60fps 帧间隔。
-
transform: translateX(100px)完全不同：它只挪图层，由 GPU 合成线程处理，不碰布局、不重绘、不阻塞主线程 - 错：
@keyframes slide { to { left: 200px; } }→ 整段动画降级回 CPU 渲染 - 对：
@keyframes slide { to { transform: translateX(200px); } }→ 真正走合成管线 - 别混用：同一动画里同时写
left和transform，浏览器会放弃硬件加速
哪些属性会让动画悄悄掉帧
浏览器不会报错，但只要 @keyframes 或 transition 里混入一个非合成属性，整条动画就退回 CPU 渲染。常见“隐形杀手”包括：
-
box-shadow：模糊计算强制 CPU 绘制，blur-radius每 +2px，显存占用平方级增长 -
filter: blur()：低端 WebView 中几乎必掉帧；filter: drop-shadow()在 Chrome 84+ 可合成，但 iOS Safari 支持弱 -
background-color、color、border-radius：触发重绘（repaint），大区域或高 DPI 屏上卡顿明显 -
width/height：改盒模型尺寸，必然重排
安全组合只有两个：transform 和 opacity。其他全删。
will-change 是定时器，不是保险丝
静态写 .item { will-change: transform; } 等于给每个元素提前建 GPU 图层，在一屏 20 个列表项的场景下，低端安卓机极易 OOM 卡死。
- 加的时机：用户交互触发瞬间（如
touchstart），或requestAnimationFrame第一帧内 - 删的时机：监听
animationend后立刻设el.style.willChange = 'auto' - iOS Safari 对 ≤16ms 动画可能不触发事件，必须加兜底：
setTimeout(() => el.style.willChange = 'auto', duration + 100) - 绝对不要写
* { will-change: transform; }或批量加到列表项上
怎么确认 GPU 加速真起了作用
写了 transform 不等于就加速了。必须看底层行为：
- Chrome DevTools → Rendering → Layers 面板：搜索含
transform的元素，看是否生成独立绿框图层；没绿框 = 还在主线程跑 - Paint flashing：开后绿色块若集中在阴影/模糊区域，说明
box-shadow或filter正在拖后腿 - 动画中哪怕只有一帧用了
margin-top或background-color，整条动画都会退化——它不警告，只默默掉帧
最容易被忽略的是：动画结束后的清理动作。不及时清 will-change、不重置 transform、不移除临时 class，下一波动画就直接继承上一轮的内存负担和图层混乱。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
