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 实际执行间隔
