卡顿主因是浏览器退回到CPU渲染，因混入非合成属性（如top/left、box-shadow、filter等）导致整段动画失效；仅transform和opacity能稳定触发GPU加速，避免重排重绘。
卡顿不是动画写得“不够好”，而是浏览器被迫退回到 CPU 渲染——只要混入一个非合成属性，整段 @keyframes 或 transition 就失效。
为什么 top/left 动画必卡
改 top 或 left 会强制触发重排（reflow），浏览器得在主线程里重新计算布局、尺寸、文本流……一次重排耗时 3–8ms，远超 16.67ms 的 60fps 帧间隔。低端安卓机（尤其 Android 5–7 WebView）一帧内反复重排，直接堵死主线程。
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 面板 → 勾选 “Layer Borders”：有绿色边框才是被提升的图层
- Layers 面板搜索目标元素：应单独显示为
GraphicsLayer，而非 “Shared with ancestor” - 打开 Paint Flashing：动画期间大面积绿色闪动 = 频繁重绘，说明没走 GPU
最容易被忽略的是：动画结束后的 will-change 残留，以及 iOS Safari 下 animationend 丢失后无人清理的状态。这两处不处理，再顺的动画也会在下一次触发时卡住。
