Chrome DevTools 如何分析脚本记录执行过程

Chrome DevTools Performance面板可无侵入式录制JS执行过程，需正确配置CPU限速、Screenshots和Memory选项，按交互或加载场景选择录制方式，在火焰图中通过Self Time定位瓶颈，并结合FPS、Layout和内存快照交叉分析性能问题。

直接用 Chrome DevTools 的 Performance 面板就能完整记录并回溯 JavaScript 的执行过程，不需要额外埋点或改代码。

录制前必须设置好关键选项

录不准，后面全白忙。打开无痕窗口（Ctrl+Shift+N 或 Cmd+Shift+N），避免插件干扰；进入 Performance 面板后，点击右上角 ⚙️ 图标，做三件事：

• CPU Throttling 选 4x slowdown 或 6x slowdown，模拟真实弱网弱机环境
• 勾选 Screenshots（截图）——能对应到每一帧画面变化
• 勾选 Memory（内存）——后续可关联 GC 和堆增长

按目标选对录制方式

不是所有操作都适合同一种启动方式：

• 想分析用户点击、滚动、动画等交互行为 → 点顶部红色圆点开始录制，操作完成后立刻停止，时长控制在 2–5 秒内
• 想查页面加载阶段的 JS 执行（比如白屏、首屏卡顿）→ 点旁边的 Start profiling and reload page，它会自动在 load 后结束

错用 reload 录制去分析点击后的逻辑，很可能根本找不到你写的函数调用栈。

在火焰图里定位执行链条

录制结束后，时间轴默认展示 Main 线程。黄色区块就是 Scripting，代表 JS 执行：

• 悬停看耗时和函数名，比如 updateList(): 68.3ms
• 点击该区块，在下方 Bottom-Up 视图中，找 “Self Time” 最高的函数——这是它自己干的活，不是被别人调用拖累的
• 展开 Call Tree，能看到完整的调用链，比如 clickHandler → fetchData → renderItems → diffDOM

注意：Scripting 长不等于代码写得差，也可能是触发了强制同步布局（Forced Synchronous Layout），这时你会看到黄色块旁边紧挨着紫色 Layout 块。

结合帧与内存交叉验证

单看脚本耗时不全面，要联动判断：

• FPS 曲线掉红？点开对应帧，看 Scripting 是否超过 16ms（60fps 预算）
• 帧详情里是否同时出现大量 Recalculate Style 或 Layout？说明 JS 在读写 DOM 属性时反复触发回流
• Memory 面板里拍两个堆快照（操作前后），对比有没有 Detached DOM、未解绑的事件监听器或闭包持有大对象——这些会让 GC 频繁介入，间接拉长 JS 实际执行间隔