fps稳定在60左右是判断js是否阻塞渲染最直观指标；chrome devtools的fps meter可实时监控，绿色（≤16.67ms）为正常，黄/红表示卡顿；performance面板结合long task可精确定位掉帧元凶。
直接看 FPS 是否稳定在 60 左右，是判断 JavaScript 运行时是否干扰渲染最直观的方式。它不反映脚本执行快慢，而是告诉你“浏览器有没有被卡住”——哪怕代码逻辑再简单，只要主线程被占满，帧率就会掉。
用 Chrome DevTools 实时查看 FPS
打开开发者工具 → More Tools → Rendering → 勾选 FPS Meter。页面左上角会实时显示当前帧率、每帧耗时（ms）、以及 GPU 图层信息。绿色表示正常（≤16.67ms/帧），黄色或红色代表单帧超时，已影响流畅度。
- 静止页面下 FPS 显示为 0 是正常的，它只对动画、滚动、交互等触发重绘的行为敏感
- 滚动时持续低于 45 FPS，大概率存在布局抖动或强制同步样式计算
- 点击按钮后 FPS 瞬间归零 1 秒以上，说明有长任务阻塞了主线程
用 Performance 面板深度定位帧率问题
录制一段典型用户操作（比如搜索、展开菜单），重点观察三块内容：
- FPS 曲线图：横轴是时间，纵轴是实时帧率。掉到 30 以下就属于肉眼可感知卡顿
- Main 线程火焰图：找宽度明显超过 16ms 的长条（尤其是 JS 脚本块），那就是导致掉帧的元凶
- Summary 面板：查看 “Scripting” 占比是否过高，若超 50%，说明 JavaScript 执行过度挤压了渲染时间
用 requestAnimationFrame 自定义监控
适合嵌入生产环境做轻量级 FPS 统计，原理是利用 raf 回调与浏览器刷新节奏同步的特性：
- 每秒统计 raf 被调用次数，就是该秒实际 FPS；连续多秒低于 55，可视为性能告警信号
- 避免高频更新 DOM 展示 FPS 数值，否则自身就成性能负担；建议用 console.count 或上报采样值
- 注意不要仅看瞬时 FPS（如 1000 / (timestamp - last)），它波动太大，掩盖真实趋势
结合 Long Task 数据交叉验证
FPS 掉帧往往和长任务强相关。开启 Performance 面板录制时，同时启用 Long Tasks 记录（默认开启）：
- 凡是持续 ≥50ms 的 JS 任务，都会被标记为 Long Task，并出现在 Main 线程下方独立轨道中
- 如果某次掉帧恰好与一个 200ms 的 Long Task 时间重叠，基本可锁定因果关系
- 常见诱因包括：未拆分的大数组遍历、同步 DOM 查询+修改混用、未节流的 resize 或 scroll 处理器
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
