Chrome DevTools Performance面板分析JS性能需遵循“录制—观察—定位—验证”四步闭环，聚焦主线程上的长任务、布局抖动和帧率下降，并结合Rendering、Memory等面板交叉验证根因。
用 Chrome DevTools 的 Performance 面板分析 JavaScript 运行时性能，核心是“录制—观察—定位—验证”四步闭环。重点不是看满屏图表，而是聚焦主线程（Main Thread）上哪些函数拖慢了交互、触发了长任务或引发布局抖动。
一、正确录制一段有代表性的操作
打开 DevTools（F12 或 Ctrl+Shift+I），切换到 Performance 面板，点击左上角录制按钮（●），然后在页面上执行你要分析的用户行为（比如点击按钮、滚动列表、打开弹窗），持续 2–5 秒后停止录制。
关键提醒：
- 确保勾选 JavaScript samples 和 Network（默认已开），避免遗漏调用栈和资源加载影响
- 不要在录制时切到其他标签页或做无关操作，防止干扰时间线
- 若目标是首屏交互，可先刷新页面再立即开始录制；若分析滚动卡顿，就专注滚动过程
二、快速识别三大关键信号
录制完成后，时间线会自动展开。重点关注顶部摘要栏和下方主视图中的三类高亮：
立即学习“Java免费学习笔记（深入）”；
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
- 红色长条（Long Tasks）：持续 >50ms 的任务，直接阻塞主线程，导致页面卡顿、输入无响应。鼠标悬停可看到具体函数名和耗时
-
Layout / Recalculate Style 区域密集：说明频繁触发样式计算与布局重排，常见于循环读写 DOM 样式（如
offsetTop+className交替调用） - FPS 曲线掉到 30 以下甚至归零：帧率骤降通常对应 JS 执行过久、大量绘制或内存压力，可下拉到底部“Frames”轨道查看单帧耗时
三、深入 Main Thread 查看调用栈
点击任意一个 Long Task 或可疑的 JS 执行块，右侧 Summary 面板会显示该任务的调用树（Call Tree）。从上往下看：
- 顶部是触发源头（如
click事件、setTimeout回调） - 中间层是你的业务函数（注意看 Self Time —— 函数自身耗时，不包含子调用）
- 底部常出现
layout、updateLayerTree、paint等渲染相关原生操作，说明 JS 已间接引发渲染开销
如果发现某函数 Self Time 占比极高（比如 80%+），它就是首要优化目标；若多数时间花在子调用里（如 JSON.parse、Array.map），就要检查入参规模或算法逻辑。
四、配合其他面板交叉验证
Performance 面板擅长“抓现场”，但需联动其他工具确认根因：
- 看到大量 Layout？切换到 Rendering 面板，开启 Layout Shift Regions 和 Paint Flashing，直观查看哪些区域反复重绘
- 怀疑内存持续增长？在录制前后分别点 Memory 面板的 “Take Heap Snapshot”，对比两次快照中 Detached DOM 节点或大型数组是否未释放
- 想精确测量某段代码？不用猜，直接用
performance.mark()和performance.measure()插桩，结果会出现在 Performance 的 Timings 轨道里
不复杂但容易忽略：每次分析前，先关掉浏览器插件、禁用所有非必要扩展，避免它们污染主线程数据。
