Chrome DevTools 的 Performance 面板，堪称分析 JavaScript 执行耗时的“手术刀”。无需安装任何插件，也不用手写额外代码，直接录制一段用户操作，就能把 JS 的“慢动作”彻底拆解清楚。关键要点：重点关注 Main 线程上的黄色区块、结合 FPS 曲线与帧详情、别忘了利用 Memory 面板辅助排查——通过这几个维度交叉验证，才能精准定位性能瓶颈。
具体操作：按下 F12 或 Ctrl+Shift+I（Win）/Cmd+Option+I（Mac） 打开开发者工具，切换到 Performance 标签页。点击顶部的红色圆点按钮开始录制；随后在页面上执行需要分析的操作——比如点击按钮、滚动页面、加载数据。再次点击停止按钮，DevTools 就会生成一份完整的性能快照。
重点观察 Main 线程上的 Scripting 时间
录制完成后，时间轴下方默认显示 Main 线程的活动。黄色区块代表 JavaScript 执行（Scripting），区块越宽说明耗时越长。判断标准：如果看到连续超过 50ms 的黄色块，那就是“长任务”，会直接阻塞页面响应。将鼠标悬停在某个区块上，可以看到具体函数名和耗时——例如 handleSearch()：42.6ms。点击该区块后，下方的 Bottom-Up 或 Call Tree 视图中，能清晰看出是哪个函数调用链占据了最多时间。
结合 FPS 与帧详情定位卡顿根源
顶部还有 FPS 曲线图，绿色表示流畅（约 60 FPS），出现红色三角则代表掉帧。点击某一帧，展开其详细的处理过程：
- 如果一帧中 Scripting 时间远超 16ms（60fps 的预算），说明 JS 拖慢了渲染
- 留意是否同时触发了大量 Layout（紫色）或 Paint（绿色）——可能是 JS 修改样式但未批量处理，导致反复回流与重绘
- 对比“Scripting”和“Rendering”的占比，判断瓶颈是纯计算问题，还是 DOM 操作引发的连锁反应
借助 Memory 面板排查隐性耗时
有些 JS 耗时高，并非逻辑本身慢，而是内存压力过大，触发了频繁的垃圾回收（GC）。此时，切换到 Memory 面板：
- 选择 Heap snapshot，在操作前后各拍一次快照，对比是否有对象未被释放——尤其是闭包、事件监听器、定时器
- 重点关注 Detached DOM trees——这类残留节点会让 GC 负担加重，间接延长 JS 执行间隔
- 如果发现 GC 频繁且耗时高，优化方向就不再是改算法，而是清理引用、解绑监听器
总的来说，一个常见但容易犯的错误是：只盯着单个函数的耗时，忽略了主线程的整体负载、帧节奏和内存状态。一次录制，多个维度交叉验证，才能真正找出 JS 耗时的真实原因。
