top/left动画必卡，因其每帧强制触发重排导致CPU满载、主线程阻塞；应改用transform/opacity，仅走GPU合成层，避免混用非合成属性，并通过Layer Borders验证图层提升。
因为用 top/left 做动画会强制每帧重排（reflow），而低端安卓机（尤其是 Android 5–7 WebView）主线程调度弱，一帧内反复重排直接堵死渲染流水线，60fps 崩到 20fps 以下。
top/left 动画为什么必卡
改 top 或 left 会让浏览器在主线程里重新计算位置、尺寸、换行、文本流……这个过程 CPU 全包。实测一次重排耗时 3–8ms，远超 16.67ms 的帧间隔。而 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第一帧内 - 删的时机：监听
transitionend后立刻设el.style.willChange = 'auto' - iOS Safari 对 ≤16ms 动画可能不触发事件，必须加兜底：
setTimeout(() => el.style.willChange = 'auto', duration + 100) - 绝对不要写
* { will-change: transform; }或批量加到列表项上
怎么确认 GPU 加速真起了作用
写了 transform 不等于就加速了。关键得看浏览器是否真建了独立图层：
- Chrome DevTools → Rendering 面板 → 勾选 “Layer Borders”：有绿色边框的元素才是被提升的合成层
- 没绿框？检查父容器是否设了
overflow: hidden或filter: blur(1px)—— 这些会抑制子元素提层 - 避免在动画元素上同时用动态变化的
box-shadow或filter，它们可能让图层合并失败
最常被忽略的一点：哪怕只是动画中调了一次 getBoundingClientRect()、offsetHeight 或 getComputedStyle()，都会强制同步 Layout，瞬间破防。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
