Chrome DevTools 的 Performance 面板，无需侵入代码或手动埋点，即可完整记录 JavaScript 的执行全过程——这无疑让性能分析变得高效省力。但要真正发挥其威力，关键配置必须到位：开启 CPU 限速（模拟弱网弱机环境）、启用截图和内存记录，并根据交互场景或加载场景选择合适的录制方式。录制完成后，在火焰图中定位 Self Time 较高的函数，再结合 FPS 曲线、布局事件和内存快照进行交叉验证，才能精准锁定性能瓶颈。
简单来说，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，它会自动在页面加载完成后停止录制。
注意：使用 reload 录制分析点击后的逻辑，很可能找不到你写的函数调用栈——因为录制的是加载过程，而非交互过程。
在火焰图里定位执行链条
录制结束后，时间轴默认展示 Main 线程。黄色区块表示 Scripting，即 JavaScript 正在执行。悬停可查看耗时和函数名，例如 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 实际执行间隔。
综合以上步骤，才能彻底理清 JavaScript 执行过程中的性能问题。
