动画卡顿本质是浏览器未在16.7ms帧预算内完成整帧工作，需用Chrome Performance面板录制定位JS执行、样式计算、Layout、Paint或Composite哪一环超时，并结合Layout抖动、低效CSS属性（如left/box-shadow）及合成层滥用等具体原因排查。
动画卡顿不是“看起来不顺”，而是浏览器在16.7ms内没完成整帧工作。排查关键不在猜，而在定位哪一环超时——是JS执行太久？样式算太慢？还是绘制拖了后腿？
用 Performance 面板真实录制动画过程
打开 Chrome 无痕窗口，进 DevTools → Performance 标签页，点击左上角录制按钮（不是“刷新后录制”），然后手动触发你要分析的动画（比如点开弹窗、滚动列表、悬停动效）。录够2–3秒就停。重点看三块：
- 火焰图顶部的 FPS 曲线：掉到 40 以下就是明显卡顿，标红区域直接对应掉帧帧号
- 主线程时间轴：展开每一帧，找耗时超过 12ms 的长任务（Long Task），点开看具体函数或样式计算堆栈
- 底部 Layers 和 Paint 面板：如果某帧里 Paint 或 Raster 耗时突增，说明重绘/光栅化压力大；若 Composite 时间高，可能是合成层过多或纹理上传慢
盯紧重排重绘和布局抖动
很多卡顿表面是动画慢，根子是 JS 在一帧里反复读写布局属性。典型模式：
- 先读
offsetHeight/getComputedStyle，再改style.width/style.margin - 循环中多次读取又多次修改同一元素的位置或尺寸
这类操作会强制浏览器同步计算布局（即“强制同步布局”），打断渲染流水线。Performance 面板里会显示为黄色的 Layout 块，且常伴随多个连续 Layout —— 这就是布局抖动。解决办法是把所有读操作集中到一起，所有写操作集中到一起，并用 requestAnimationFrame 批量提交。
立即学习“前端免费学习笔记（深入）”；
检查是否误用了低效动画属性
不是所有 CSS 属性都适合动画。浏览器对 transform 和 opacity 做了深度优化：它们不触发布局和绘制，只走合成管线，GPU 可加速。而 left、top、width、height、box-shadow、border-radius 等属性，每帧都会引发重排或重绘。
你在动画中改了 box-shadow 渐变？哪怕只有一行，它就可能让整页滚动卡住——就像抽奖页那个遮罩案例。打开 Elements 面板，选中动画元素，看 Computed 标签页里 “Layout Shifts” 和 “Repaints on scroll” 是否被频繁触发。优先把位移换成 transform: translateX()，透明度用 opacity，必要时加 will-change: transform 提前升层。
验证合成层与内存开销
启用硬件加速不等于万事大吉。过度使用 transform + will-change 会创建大量独立合成层，每个层都要分配 GPU 内存、做纹理上传和混合。低端安卓机尤其敏感。
- 在 DevTools 的 Rendering 面板勾选 “Layer Borders”，看动画元素是否意外包裹了太多父级层，或出现大量半透明小块
- 用 Memory 面板拍几张快照，对比动画开启前后 DOM 节点数、监听器数、JS 堆大小是否异常增长
- 注意
will-change不要提前声明在静态样式里，应在动画开始前 JS 动态添加，结束后及时移除
