移动端CSS动画卡顿主因是使用top/left/width等触发重排的属性或滥用will-change；应仅用transform和opacity，动态控制will-change并验证图层提升。
移动端 CSS 动画卡顿，90% 不是因为没开 GPU 加速，而是用了 top、left、width 这类属性触发重排，或者把 will-change 当成常驻开关乱加。
为什么用 top/left 动画必卡
改 top 或 left 会强制浏览器每帧都重新计算布局（reflow），这个过程全靠 CPU，在低端安卓机上单次耗时常达 3–8ms，远超 16.67ms 的 60fps 帧间隔。动画一动就“一顿一顿”，不是卡在 GPU，是卡在主线程被堵死。
- 错：
@keyframes slide { to { left: 200px; } }→ 整段降级回 CPU 渲染 - 对：
@keyframes slide { to { transform: translateX(200px); } }→ 真走合成管线 - 别混用：同一
transition里同时写left和transform，浏览器直接放弃硬件加速 - 初始定位要归零：若元素本身有
position: relative; top: 10px;，动画前先用transform: translateY(-10px)抵消，否则位移起点不准且可能触发意外重排
will-change 必须动态控制，不能写死在 CSS 里
will-change: transform 不是性能开关，是“预告”——浏览器看到它就会提前分配 GPU 内存、创建独立图层。元素不动却一直挂着，等于白占资源，还可能引发合成器抖动。一屏 20 个卡片全加，低端机极易 OOM 卡死或 WebView 回收白屏。
- 加的时机：用户真实交互瞬间，比如
touchstart或mouseenter事件中通过 JS 添加 class，如.card.is-animating - 删的时机：监听
animationend（不是transitionend）后立刻移除 class；若用 JS 动画，最后一帧设el.style.willChange = 'auto' - iOS Safari 对 ≤16ms 动画可能不触发事件，必须加兜底：
setTimeout(() => el.style.willChange = 'auto', duration + 100) - 绝对不要写
* { will-change: transform; }或批量加到列表项上
怎么确认 GPU 加速真起了作用
写了 transform、加了 will-change，不代表真加速。很多卡顿根源根本不在动画本身，比如图片未压缩、JS 执行阻塞、box-shadow 太重，加了也救不了。
立即学习“前端免费学习笔记（深入）”；
- Chrome DevTools → Cmd+Shift+P 输入 “Rendering” → 勾选
Layer borders：有绿色细边框才是被提升的图层；若显示为 “Shared with ancestor”，说明没升层 - 同面板勾选
Paint flashing：动画期间大面积绿色闪烁 = 频繁重绘，说明没走 GPU，得查是不是混入了background-color、border-radius等属性 - Layers 面板搜索目标元素：应单独显示为
GraphicsLayer，而不是嵌套在父层里 - 注意：iOS Safari 对
will-change: contents支持极弱，且会强制子树全升层，极易图层爆炸，一律避开
真正决定丝滑与否的，不是“有没有开 GPU”，而是“有没有让浏览器少干活”。守住 transform 和 opacity 这两条底线，按需升层、及时清理、验证图层，比堆参数管用得多。
