关键在于前置条件卡死：必须用无痕窗口、network禁用缓存、cpu节流4x、勾选screenshots和memory；record与start profiling不可混用；火焰图中先看>50ms黄色块标签定位js触发的layout/style/composite问题，再按self time排序call tree找耗时函数。
直接用 Chrome DevTools 的 Performance 面板分析 JS 运行时性能，关键不是“怎么点按钮”，而是前置条件卡死、操作路径明确、火焰图读对位置。录错一次，80% 的数据就失效。
必须做的录制前准备
这些不是建议，是硬性门槛：
- 用无痕窗口打开页面（Ctrl+Shift+N 或 Cmd+Shift+N），彻底隔离插件、缓存、预加载脚本干扰
- 在 Network 面板中勾选 Disable cache（Performance 面板里没有这个选项，漏掉会导致首屏解析阶段丢失）
- 点击 Performance 右上角齿轮 ⚙️，设置三项：
— CPU Throttling 选 4x slowdown（拉长 JS 执行时间，让 32ms 的任务变成 128ms，才能看清谁在拖慢主线程）
— 勾选 Screenshots（把 FPS 曲线上的红条和实际画面卡顿对应起来）
— 勾选 Memory（观察 DOM 节点突增、Detached DOM 不释放等 JS 内存问题）
Record 和 Start profiling 的区别不能搞混
两个按钮触发的是完全不同的录制逻辑：
- 点左上角 ● Record 按钮：适合分析用户主动行为，比如点击按钮后动画卡顿、滚动列表掉帧。操作前立刻点，操作完成马上停，时长控制在 2–5 秒内最清晰
-
点旁边的 Start profiling and reload page：只用于页面加载性能。它会在
DOMContentLoaded和load后自动停止，适合查白屏、资源阻塞。想看点击后的requestAnimationFrame却用了这个，调用栈根本不会出现
火焰图里怎么看 JS 性能瓶颈
别一上来就钻进 JS 函数堆栈，先抬头看横条上方的标签：
- 看到横跨 >50ms 的黄色块，先看它头顶写的什么：
— 标着 Layout：说明 JS 触发了强制重排
— 标着 Recalculate Style：样式计算被反复打断
— 标着 Composite Layers：合成层阻塞，可能和 will-change、transform 等滥用有关 - 大量 Forced Synchronous Layout 提示？大概率代码里有类似
el.offsetHeight后紧跟el.style.top = ...的读写交替，浏览器被迫同步回流 - 想定位具体哪段 JS 耗时最多：切到 Call Tree 标签页，按 Self Time 排序，排在最上面的函数就是真正占用主线程的“罪魁”
分析时盯住三个核心指标
不用全图扫描，聚焦这三个轨道就能快速判断：
- FPS 轨道：红色竖条代表掉帧（>33ms），尤其注意是否集中在某次点击或滚动后——那是 JS 执行或渲染阻塞的直接证据
- CPU 轨道：紫色（Rendering）持续高位 → 布局/绘制压力大；黄色（Scripting）堆成山 → JS 执行过载，结合 Call Tree 查 Self Time
- 内存曲线（勾选 Memory 后才有）：DOM 节点数陡升后不回落 → 内存泄漏；JS Heap 持续上涨 → 对象未释放；Detached DOM 数量多且不归零 → 事件监听器或引用没清理
