直接打开performance面板录制真实交互即可暴露多数性能问题，关键在于精准启动与聚焦主线程火焰图、fps图表、网络请求三类核心区域分析。
直接打开 Performance 面板录制一次真实交互，就能暴露多数性能问题。关键不是录得久，而是录得准、看得懂。
一、正确启动录制
别点完就跑——先设好环境再开始：
- 勾选 “Screenshots”（截图）：生成帧图，直观看到卡顿或空白帧
- 在 Network 下拉菜单中选 “Fast 3G” 或自定义限速：模拟真实弱网加载行为
- 在 CPU 下拉菜单中选 “4x slowdown”：放大 JS 执行耗时，让小瓶颈变明显
- 点击红色圆点开始录制，然后执行目标操作（比如点击按钮、切换 Tab、滚动到底部），操作完成后立刻停录
二、聚焦三类核心区域找问题
录制完成后，时间轴会显示多层轨道。不用全看，盯住这三块：
- 主线程（Main）火焰图：纵向堆叠的长条代表 JS 执行、样式计算、布局、绘制等任务。出现连续 >50ms 的长条，大概率是 JS 阻塞或重排重绘过重
- FPS 图表（绿色条）：低于 60fps 就掉帧。若某段持续
- 内存图表（蓝色线）：上升后不回落，尤其在重复操作后阶梯式增长，提示可能存在内存泄漏（比如事件监听未卸载、闭包持有 DOM 引用）
三、下钻定位具体代码位置
找到可疑长任务后，双击它进入详情：
- 看 Call Stack 标签：从上往下读，最顶层是你触发的事件（如 click），往下是实际耗时函数——重点看自己写的模块名（如
renderTable、processImageData） - 留意 Self Time：数值高说明该函数本身开销大，而非调用子函数所致；若 Self Time 低但 Total Time 高，说明它调用了多个慢子函数
- 右键函数名 → “Reveal in Sources panel”：自动跳转到源码行，方便加断点或插入
console.time()进一步细分
四、对比验证优化效果
改完代码后，别只看“好像快了”——要量化验证：
- 用同一套操作路径重新录制（保持网络/CPU 设置一致）
- 拖动时间轴，用 “Summary” 面板对比两次的 Scripting 和 Rendering 总耗时变化
- 重点关注最大单次任务时长是否降到 16ms 以内（保障 60fps）
