卡顿主因是浏览器每帧执行layout或paint而非gpu合成，应排查@keyframes中是否含top/left/width/height等高开销属性，改用transform或opacity；验证元素是否升层（layer borders）、合理使用will-change、避免js强制同步布局。
卡顿不是animation写得不够“炫”，而是浏览器每帧都在做 layout 或 paint，根本没进 GPU 合成通道。
检查是否用了触发重排的属性
打开 DevTools → Elements → 选中动画元素 → 看 Styles 面板里生效的 animation 关键帧。重点排查这些高开销属性是否出现在 @keyframes 中：
-
top、left、width、height -
margin、padding、background-position -
box-shadow（尤其带模糊半径）、filter（链式或 blur > 4px）
只要其中任一属性参与动画，浏览器就必须每帧重新计算布局和绘制，60fps 直接崩到 20–30fps。替换成 transform: translateX(100px) 或 opacity: 0.3 才能走合成线程。
确认元素是否真正升层为独立合成图层
用了 transform 不等于自动硬件加速——浏览器只对已提升为合成层的元素启用 GPU 合成。验证方式：DevTools → Rendering → 勾选 “Layer borders”。绿色边框才表示升层成功。
- 没边框？加
transform: translateZ(0)和backface-visibility: hidden两行 CSS，缺一不可 - 加了还是没边框？检查父容器是否有
overflow: hidden或will-change: transform覆盖了子元素升层策略 - iOS Safari 对
filter: blur()升层支持极弱，安卓 WebView 中backdrop-filter可能直接降级为 CPU 绘制
避免 will-change 滥用和静态挂载
will-change 是内存预告，不是性能开关。全局写 .item { will-change: transform; } 会导致整页图层数暴涨，低端机直接白屏或耗电翻倍。
- 正确做法：在触发动画前 1–2 帧用 JS 动态设置
el.style.willChange = 'transform'，动画结束立刻设为'auto' - 监听
animationend事件清除，别依赖 CSS 自动恢复 - 长列表中慎用——每个
.list-item都加will-change，显存占用会随可视区 item 数线性增长
验证是否真掉帧，而不是错觉
别只盯着 animation-duration 调来调去。打开 Chrome DevTools → Performance 面板录制一段动画，重点看三项：
- 主线程火焰图中
Layout或Update Layer Tree占比是否超过 15% - Rendering 标签页勾选 “Paint flashing”，动画区域外是否大面积闪绿（说明重绘失控）
- FPS meter 是否长期低于 50，且柱状图断续不连贯
最常被忽略的一点：JS 在 requestAnimationFrame 里读取 getBoundingClientRect() 或 offsetTop，会强制同步 layout，直接打断渲染流水线——这个坑比 CSS 写错更隐蔽，也更难定位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
