应直接测量组件交互过程中的帧率变化，通过模拟真实操作、固定测量方式、抓准下降区间，用performance.now()或requestAnimationFrame采样至少180帧，结合Chrome Performance面板分析FPS轨迹、长任务及样式重计算耗时，并统计p90帧耗时、最大单帧耗时和达标帧占比，确保测试环境纯净且可复现。
直接测组件交互过程中的帧率变化，而不是只看“平均FPS”这种模糊数字。关键在于模拟真实操作、固定测量方式、抓准下降区间。
明确测试场景和操作序列
不能随便点两下就截图比FPS。要设计可复现的用户行为：
- 比如列表滚动3秒、点击按钮触发100次状态更新、切换Tab重新挂载子组件
- 每次操作从同一初始状态开始（清空缓存、重置数据、卸载再挂载）
- 用
performance.now()或requestAnimationFrame打点采样，持续记录帧耗时，至少采集180帧（3秒@60fps）
用 Chrome Performance 面板抓主线程瓶颈
打开 DevTools → Performance → 点录制 → 执行操作 → 停止 → 分析：
- 筛选 “Rendering” 和 “Scripting” 区域，看长任务是否变短
- 查看 FPS 轨迹曲线：优化前是否频繁跌破45fps？优化后是否稳定在55–60fps？
- 注意“Recalculate Style”和“Layout”块长度——如果它们缩短了，说明v-for重排或响应式依赖链变轻了
对比帧耗时分布，不止看平均值
平均FPS掩盖抖动。你应该统计：
- 90分位帧耗时（p90）：代表大多数帧的上限，比平均值更有参考价值
- 最大单帧耗时：是否从40ms降到12ms？这直接影响卡顿感
- 低于16.67ms（60fps）的帧占比：从70%提升到95%，才是有效优化
避免干扰因素，确保结果可信
- 测试全程用无痕模式 + 关闭所有浏览器插件
- 固定设备与系统负载（关掉微信、钉钉、杀毒软件）
- 同一 Chrome 版本（建议 124+），禁用硬件加速以外的实验性功能
- 组件用
defineComponent({ name: 'TestComp' })显式命名，方便在 Vue Devtools 中过滤定位
不复杂但容易忽略。
