CSS动画卡顿主因是触发重排，仅transform和opacity可稳60fps；需避免top/left等属性、filter/box-shadow等重绘操作；will-change须动态控制；JS读取布局信息会破坏优化；须用Layers面板验证图层是否独立。
低端安卓机（尤其是 Android 5–7 WebView）上 CSS 动画卡顿，根本不是“没开硬件加速”，而是你写的动画属性本身触发了重排（reflow）——top、left、width、height、margin 这些一动，CPU 就得每帧重算整个文档流，主线程直接堵死。真正能稳住 60fps 的，只有 transform 和 opacity。
用 transform 替代 top/left 是最直接有效的修复
改一个属性就能大幅改善，不需要 JS、不增加运行时负担，关键是绕过重排：
-
left: 100px→ 改成transform: translateX(100px) -
top: -20px→ 改成transform: translateY(-20px) - 居中写法
left: 50%; top: 50%; transform: translate(-50%, -50%)已经是安全的，不用动 - 绝对不要混用：同一段
@keyframes或transition里同时出现left和transform，浏览器会整段降级回 CPU 渲染
filter、box-shadow、background-color 是隐形掉帧元凶
这些属性看起来“只是视觉变化”，但它们会强制重绘（paint），在低端机上尤其致命：
-
filter: blur(2px)或drop-shadow()在 Android 5–7 WebView 中几乎必掉帧，CPU 做高斯模糊，一帧耗时翻倍 -
box-shadow、border-radius、background-color动画会触发大面积重绘，高 DPI 屏上更明显 - 哪怕只加一个
box-shadow到@keyframes里，整段动画就退回软件渲染——浏览器不会报错，但帧率会悄悄跌到 30fps 以下 - 安全组合只有：
transform+opacity；其他全删
will-change 不是保险丝，是定时器，必须动态控制
静态写 .item { will-change: transform; } 等于给每个元素提前建 GPU 图层，在一屏 20 个列表项的场景下，低端安卓机极易 OOM 卡死：
- 正确时机：在用户交互开始前（如
touchstart）或requestAnimationFrame第一帧内设置el.style.willChange = 'transform' - 必须清除：监听
transitionend或animationend后立刻设为el.style.willChange = 'auto' - iOS Safari 对 ≤16ms 的动画可能不触发事件，加兜底：
setTimeout(() => el.style.willChange = 'auto', duration + 100) - 绝对不要写
* { will-change: transform; }或批量加到列表项上
JS 读取布局信息会悄悄破坏所有优化
即使你 CSS 全写对了，只要动画过程中 JS 偷偷调了一次 getBoundingClientRect()、offsetHeight、clientWidth 或 getComputedStyle()，就会强制同步重排，打断渲染流水线：
- 所有布局读取操作尽量前置，在动画开始前一次性获取并缓存
- 避免在
requestAnimationFrame回调里一边读一边写，这是典型的 Layout Thrashing - 检查第三方库（比如某些轮播组件、滚动监听插件）是否在动画中偷偷读取了
scrollLeft或boundingClientRect - 用 Chrome DevTools 的 Rendering 面板勾选 “Layout Shift Regions” 可直观看到哪些操作触发了重排
最容易被忽略的点是：写了 transform 不等于就加速了。必须打开 Chrome DevTools → Layers 面板，确认目标元素是否真的成了独立 GraphicsLayer，而不是显示为 “Shared with ancestor”。图层没提上去，再好的写法也白搭。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
