chrome performance面板可定位动画卡顿根源：一、f12打开面板录制5–8秒完整动画；二、通过fps图表（绿色/红色柱）、主线程火焰图颜色块（黄=js执行、紫=layout、绿=paint）识别瓶颈；三、依纯css、js驱动或多动画并发类型针对性优化；四、对比优化前后fps稳定性、layout/paint块宽度及长任务数量验证效果。
直接用 Performance 面板录制动画过程，就能定位卡顿根源并针对性优化——关键不在录，而在看懂时间轴里那些颜色块代表什么。
一、正确录制动画性能数据
打开 DevTools（F12）→ 切换到 Performance 面板 → 点击左上角圆形录制按钮 → 在页面上完整触发一次目标动画（比如点击弹出菜单、滚动触发动画）→ 等待动画结束再点停止。建议录制时长 5–8 秒，确保覆盖动画起始、峰值和收尾阶段。
小技巧：勾选右上角“Screenshots” 可同步捕获帧画面，方便对照视觉卡顿点；开启“FPS meter”（按 Ctrl+Shift+P 输入 “fps” 启用），右上角实时显示当前帧率。
二、聚焦三类关键指标
FPS 图表：绿色柱状图代表每秒帧数，持续低于 60（尤其掉到 30 以下）即存在明显卡顿。红色尖峰是掉帧信号，需立即下钻分析。
主线程火焰图（Main）：横向展开后，重点找：
- 长时间黄色/紫色块（JavaScript 执行）→ 检查是否在动画中做复杂计算或频繁 DOM 修改
- 密集浅绿色块（Recalculate Style）→ 样式规则过多或选择器太深
- 重复出现的浅蓝色块（Layout）→ 动画属性如
width、left触发重排 - 宽幅橙色块（Paint）→
box-shadow、border-radius或大图层反复绘制
三、快速识别动画瓶颈类型
纯 CSS 动画卡顿：火焰图中 Layout/Paint 占比高，且 Main 线程无明显 JS 块 → 检查是否用了 top、margin、height 等触发重排的属性；改用 transform 和 opacity 替代。
JS 驱动动画卡顿：火焰图中出现长条黄色 JS 执行块，尤其在动画循环内 → 检查是否在 requestAnimationFrame 中做了 DOM 查询、样式读取（如 offsetTop）、或未节流的事件处理。
多动画并发卡顿：FPS 图表整体波动大，火焰图中多个动画任务堆叠 → 减少同时运行的动画实例数量，或对非视口内元素暂停动画（如 IntersectionObserver 控制）。
四、验证优化是否生效
每次修改后，用相同操作路径重新录制一次，对比三项核心数据：
- FPS 图表是否从频繁红区回归稳定绿色区间
- Main 线程中 Layout/Paint 块是否变窄或消失
- 总录制时长内长任务（>50ms 的紫色块）是否减少
若仍有卡顿，可切换到 Layers 面板查看是否图层过多或单图层尺寸超大（如全屏动画未启用 will-change: transform）。
