performance面板时间轴与动画实际运动对不上，根本原因在于录制未对齐动画真实起点或周期：需先触发动画（如hover、addclass），再启动录制，且时长须覆盖完整周期（含delay），并排除扩展干扰、非合成属性及css规则覆盖影响。
Performance 面板里动画时间轴和实际运动对不上
根本不是面板“不准”，而是你录的那段性能数据没对齐动画的真实起点或周期。Chrome Performance 面板记录的是**从点击录制那一刻开始的完整渲染流水线**，但 CSS 动画可能在你点下录制前就已开始、中途暂停，或依赖 hover/class 切换等瞬时触发条件——这些状态不会被自动捕获。
- 别在动画静止时点录制：必须先让动画真正跑起来（比如 hover 元素、手动 addClass），再按
Ctrl+Shift+P→ 输入Record→ 回车启动；左上角红色录制按钮默认不抓合成器帧，容易漏关键信息 - 确保录制时长覆盖至少一个完整动画周期：例如
animation-duration: 1.2s; animation-delay: 0.3s，那就至少录 2s，否则看不到 delay 后的首帧和循环衔接点 - 禁用所有浏览器扩展、清空缓存、保持标签页活跃：第三方脚本或后台节流会干扰 rAF 调度，导致帧时间抖动，让时间轴看起来“漂移”
- 检查是否误用了非合成属性：如果动画改的是
left或background-color，Performance 面板里会出现密集的 purple（Layout）和 green（Paint）块，此时看到的“卡顿”是真实发生的重排重绘，不是面板误差
为什么 FPS 轨道红条位置和肉眼感觉不一致
FPS 轨道里的红色竖条表示该帧渲染耗时 ≥ 16.67ms（即低于 60fps），但它只反映**单帧耗时**，不反映连续性。人眼感知卡顿的关键是“连续两帧
- 不要只盯单个红条：拖动时间轴，看红条是否成对或成片出现；连续两个红条之间间隔
- 注意 “Dropped frame” 提示：在
Animation Frame Fired事件里出现这个标记，说明浏览器根本没来得及渲染那一帧——这是比红条更严重的信号 - 对比
Self Time：如果某帧的 red bar 下方Self Time占比极高（比如 >80%），说明瓶颈在 JS 执行，不是 CSS 动画本身；这时候优化方向是拆分逻辑或加requestIdleCallback
录制后关键帧偏移、duration 显示和代码不符
这通常不是 Performance 面板的问题，而是 CSS 层面存在隐式覆盖或计算延迟。DevTools 显示的 duration 和 delay 值，是它在录制时刻从 computed style 中读取的最终生效值，不是你写的源码值。
- 检查是否有其他规则覆盖：比如你在
.spinner上写了animation-duration: 0.8s，但媒体查询或更高优先级选择器又设成了1.5s，Performance 面板显示的就是后者 - 留意
animation-play-state的影响：如果初始是paused，首次running时，animation-delay会从“变为 running 的那一刻”开始计时，而不是元素插入 DOM 的时刻 - 伪元素动画要单独验证：
::before和::after的动画参数是独立计算的，Performance 面板里会作为两个独立 track 出现，别误以为是同一个动画的偏移
同一段动画，在 Mac 和 Windows Chrome 上录制结果不同
这不是 bug，是底层渲染调度差异。macOS 使用 Core Animation，Windows 用 DComposition，两者对合成层提升、帧提交时机的处理略有不同。尤其在低负载或高 DPI 场景下，这种差异会被放大。
- 别跨平台比对 exact 时间戳：关注趋势（比如是否都出现连续红条）、关键阶段耗时占比（Layout/Paint/Composite 各占多少）
- 在目标设备上调试：iOS Chrome 卡顿问题必须真机 + iOS Chrome 录制，模拟器或桌面 Chrome 无法复现其合成器限制
- 检查
chrome://gpu页面：确认 “Graphics Feature Status” 里 “Compositing” 和 “Rasterization” 是否均为Hardware accelerated；任一为Software only，动画就会退回到 CPU 渲染
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
