使用Chrome DevTools Performance面板录制火焰图，重点识别横向宽、纵向深的红色长条函数块——它们是执行时间长、阻塞主线程的耗时函数；需精准录制问题场景、看懂火焰图信号、交叉验证排除干扰，并用Performance API精确定位代码行级耗时。
直接用 Chrome DevTools 的 Performance 面板录制并查看火焰图，重点找横向宽、纵向深的红色长条函数块——它们就是页面中实际执行时间长、阻塞主线程的耗时函数。
一、精准录制，锁定问题场景
不要随意点“录制”就完事。先明确你要分析的具体行为：是首页加载慢？点击按钮后卡顿？还是滚动列表时掉帧？然后在 Performance 面板中勾选 Memory 和 Screenshots，点击录制 → 执行该操作 → 立即停止。这样捕获的数据才聚焦、可复现。
- 避免在空闲或非典型状态下录制，否则火焰图里全是 idle，看不出真实瓶颈
- 一次只测一个动作，比如只点一次按钮，不要连点或快速切换，干扰数据判断
- 若问题偶发，可开启 Record continuously until stopped（右上齿轮设置），再复现问题后倒查
二、看懂火焰图，识别长耗时函数
录制完成后，主区域显示火焰图。顶部是时间线，中间是调用栈（从左到右是执行顺序，从上到下是嵌套深度），底部是具体函数名和耗时宽度。关键信号有三个：
- 红色长条（Long Task >50ms）：主线程被独占超过 50 毫秒，用户会明显感知卡顿；点开它，右侧 Summary 会列出耗时最高的函数及其调用路径
- 横向特别宽的函数块：说明该函数本身执行久，比如 JSON.parse 大数据、未优化的 for 循环、同步正则匹配等
- 纵向嵌套很深的窄条堆叠：往往是事件回调层层触发、闭包链过长，或递归未收敛，也会拖慢整体响应
三、交叉验证，排除干扰因素
仅靠火焰图可能误判。需结合其他面板确认是否真是 JS 函数的问题：
- 打开 Summary 面板，看 Scripting 占比是否长期高于 50%：高则大概率是 JS 执行重；如果 Rendering 或 Painting 高，问题可能出在样式计算、强制同步布局（FSL）或大量 DOM 写入，不一定是函数本身慢
- 检查是否有高频 Layout / Recalculate Style：比如在循环中反复读取 offsetTop、clientWidth，会触发浏览器反复回流，表现为“JS 耗时高”，实则是 DOM 操作模式错误
- 切到 Memory 面板拍两个 Heap Snapshot（操作前/后），对比 Detached DOM 是否增长：若有，说明某些函数绑定了未清理的监听器或闭包引用，导致内存堆积、GC 频繁，间接拖慢运行速度
四、代码内定位，缩小排查范围
当火焰图指出某函数可疑，但不确定是哪一行耗时，可用 Performance API 辅助精确定位：
- 在函数入口加 performance.mark('fn_start')，出口加 performance.mark('fn_end')，再调用 performance.measure('fn_total', 'fn_start', 'fn_end')
- 执行后运行 performance.getEntriesByName('fn_total')[0]?.duration 查看真实毫秒级耗时
- 配合 PerformanceObserver 自动监听 measure 类型，避免手动取值遗漏
- 注意：不要边打断点边测，暂停会污染 timing 数据；标记后应直接 Resume 让代码连续跑完
