浏览器的 Performance 面板（以 Chrome DevTools 为例）是前端性能排查最核心的工具。它能够录制页面运行时的完整时序数据，帮助你精确找到卡顿帧、长任务以及执行过久的脚本，是优化 React 应用性能的“听诊器”。
22.2.1 打开并使用 Performance 面板
- 打开 Chrome DevTools（F12 或右键“检查”）。
- 切换到 Performance 面板。
- 点击左上角的 ● 录制 按钮，在页面上执行你想要分析的交互（如点击按钮、滚动列表、表单输入等），然后点击 ■ 停止。
- 录制结束后，面板会生成一份详细的性能分析报告。
技巧：在录制之前，可以先手动触发一次“垃圾回收”（点击 Performance 面板右上角的垃圾桶图标），减少回收过程对分析结果的干扰。
22.2.2 理解性能报告的关键信息
报告区域主要分为三部分：概览图、火焰图和细节面板。
概览图（Overview）
- FPS（帧率）：绿色条越高，帧率越流畅。如果出现红色条或明显的下凹，说明发生了掉帧。
- CPU：展示各类任务（脚本、渲染、布局等）对 CPU 的占用情况。
- 屏幕截图：可选显示，方便对照视觉变化。
火焰图（Main）
这是最关键的区域，以“火焰”形态展示主线程上每个任务的调用栈。每个横条代表一个函数调用，横条越宽，执行时间越长。你可以通过点击、缩放、拖拽来聚焦任意时间段。
细节面板：选中火焰图中的任意一个方法后，下方会显示其具体耗时、调用栈、源文件位置等信息。
22.2.3 定位“长任务（Long Task）”
浏览器主线程一次只能做一件事，如果某个任务（通常是脚本执行）连续霸占主线程超过 50ms，就会导致掉帧，用户会感知到明显的卡顿。Chrome 会在火焰图中用红色虚线三角标记长任务，非常醒目。
查找步骤：
- 在火焰图中找到红色三角标记的长任务块。
- 点击该任务块，火焰图会放大该任务的调用栈。
- 逐层展开调用树，找到自耗时（Self time）最长的那个函数，它通常是导致卡顿的根源。
React 中的常见肇事者：
render阶段计算大量的useMemo数据、不必要的组件重渲染、深层组件树的 reconciliation，或者副作用中执行了高频同步计算。
22.2.4 关联到 React 源代码
Performance 面板本身只能看到编译后的函数名和栈帧，难以直接对应到 React 组件。此时可以结合 React DevTools 的 Profiler 一同使用。更好的方式是在 Performance 面板中开启“记录 JavaScript 堆栈”并配合 source map。
- 录制时确保勾选 Screenshots 和 Memory（如果怀疑内存问题）。
- 在火焰图中找到长任务对应的代码块。
- 如果项目开启了 source map，点击右侧文件名链接会直接跳转到 Sources 面板中的原始代码位置（如某个组件的 render 函数或 effect 回调）。
- 结合 Bottom-Up（自下而上） 视图，按总耗时排序，可以快速看到哪个函数及其调用的子函数累积耗时最多。
22.2.5 常见卡顿模式与定位方法
| 现象 | 火焰图特征 | 可能原因 |
|------|-----------|----------|
| 点击按钮后长时间无响应 | 出现一个横跨数百毫秒的黄色或红色长任务，内部大量 layout 和 paint | 状态更新导致大量同步重渲染，或触发了同步的 DOM 布局计算（强制同步布局） |
| 页面滚动时持续掉帧 | 多个连续的长任务，FPS 锯齿状 | scroll 事件或动画中进行了昂贵的计算，没有用 requestAnimationFrame 防抖；也可能是 useEffect 中频繁触发了 setState 导致连锁渲染 |
| 列表渲染首次出现卡顿 | 首屏渲染阶段有一个很长的紫色任务（Rendering）+ 黄色（Scripting） | 列表过长且未虚拟化，一次性创建过多 DOM 节点；或使用了深层嵌套的组件，导致 reconciliation 时间剧增 |
22.2.6 实战示例：定位一个虚拟列表的卡顿
假设你发现一个包含 1000 条数据的消息列表在滚动时有明显卡顿。
- 打开 Performance 面板，开始录制，然后用鼠标快速滚动消息列表，停止录制。
- 观察概览的 FPS 图表，发现滚动过程中频繁出现红色掉帧标记。
- 放大火焰图，发现每帧（约 16.7ms 的框线）中都嵌入了若干长任务，点开后调用栈顶部是
onScroll事件处理函数。 - 在火焰图中进一步展开
onScroll，发现某个setState触发了大量render，进而导致layout和paint。 - 结合 React DevTools Profiler，发现
MessageItem组件在每次滚动时都重新渲染了，而实际上只有滚动位置发生变化，消息内容并未改变。 - 解决方案：使用
React.memo包裹MessageItem，并确保传递给它的props引用稳定（例如onClick用useCallback缓存）。再次录制验证，长任务消失，FPS 稳定。
22.2.7 使用摘要面板快速诊断
在录制结束后，切换到 Summary（摘要）标签，它会以饼图展示主线程各类活动的耗时占比：
- Scripting（脚本）：过高说明 JS 执行时间过长，可能是组件渲染、数据计算或事件处理。
- Rendering（渲染）：过高说明样式计算、布局时间久，可能是触发了大量回流或样式作用范围过大。
- Painting（绘制）：过高说明绘制成本高，可能涉及阴影、滤镜或大型 Canvas 等。
通过摘要可以快速锁定问题类别，然后到火焰图中进一步定位具体代码。
22.2.8 实用技巧总结
- 只录制关注的时间段：在执行卡顿操作前后使用
console.profile('label')和console.profileEnd('label')在代码中自动标记性能区间，面板中会显示对应标记。 - 对比正常与卡顿帧：分别录制操作前后的性能快照，对比火焰图的宽度差异，定位增多的函数调用。
- 启用 CPU 节流（Throttling）：在 Performance 面板设置中降低 CPU 速率（如 4x/6x 减速），模拟低端设备，让卡顿更容易复现。
- 结合 Lighthouse 审计：先用 Lighthouse 识别总体性能问题，再用 Performance 面板深入微观分析。
- 关注布局抖动（Layout Thrashing）：如果在火焰图中看到连续的紫色“Layout”栏，说明可能发生了强制同步布局，需检查代码中是否循环读取 offsetHeight/offsetWidth 等属性并立即修改样式。
掌握浏览器 Performance 面板，你就拥有了精准定位 React 应用卡顿的“显微镜”。当用户抱怨“这个页面好卡”时，你不再需要凭空猜测，而是能够直接提取证据，找到精确到行号的性能瓶颈。这才是工程化性能优化的真正起点。