chrome devtools performance面板是分析脚本评估耗时最直接有效的工具，可精准定位单次超50ms的长任务及其具体代码行，结合fps、cpu轨道和火焰图识别主线程阻塞源头。
Chrome DevTools 的 Performance 面板是分析脚本评估（Script Evaluation）耗时最直接、最有效的工具。它能精确告诉你哪段 JS 执行了多久、在什么时机阻塞了主线程，而不是靠猜或日志估算。
重点不是“总耗时”，而是“谁在什么时候干了什么、干了多久” —— 尤其关注单次执行超 50ms 的长任务（Long Task），因为它们会直接导致卡顿和掉帧。
? 一、录制前准备：让数据更真实可靠
用隐身窗口打开页面
避免浏览器插件、缓存、扩展干扰性能数据。-
禁用缓存 + 模拟弱网/弱 CPU
- Network 面板勾选 Disable cache
- Performance 面板右上角 ⚙️ → Capture Settings →
✅ 勾选 Screenshots（看卡顿时画面是否冻结）
✅ 勾选 Memory（关联内存增长排查泄漏）
⚙️ CPU Throttling 选 4x slowdown（暴露移动端易被忽略的瓶颈）
操作要典型、集中、可复现
比如：点击搜索按钮 → 等待结果渲染 → 滚动列表前 3 屏。整个过程控制在 4–6 秒内，避免噪声干扰。
? 二、识别脚本评估耗时的关键位置
录制完成后，重点关注三个区域：
FPS 轨道（顶部绿色条）
出现红色竖条 = 当前帧耗时 >16.7ms（60fps 容忍上限），说明有卡顿。往下对齐找主线程活动。CPU 轨道（紫色/黄色堆积区）
黄色块代表 Scripting（JS 执行），紫色是 Rendering（样式计算+布局+绘制）。如果某段黄色持续宽于 50ms，就是高危长任务。Main 火焰图（中部主视图）
横向宽度 = 耗时，纵向嵌套 = 调用栈。
? 直接拖选一段宽黄条 → 底部切换到 Call Tree 标签 → 按 Self Time 降序排列
→ 找到占比最高、非框架/库代码的业务函数（比如handleSearchSubmit、renderProductList）
? 三、定位具体代码行的两种方式
点击火焰图中的函数名
若源码映射正常（未压缩 / 有 sourcemap），会自动跳转到 Sources 面板对应文件和行号，可立刻查看上下文。-
看 Summary 面板中的 Task 类型
选中一个长任务后，Summary 显示：-
Task Type:
ScriptEvaluation - Duration: 82.4 ms
-
Call Stack: 展开后能看到从
setTimeout→initPage→parseData的完整链条
→ 最深那一层、Self Time 最高的，就是瓶颈源头。
-
Task Type:
⚙️ 四、补充手段：控制台快速验证片段耗时
对怀疑的逻辑块，可临时加计时辅助判断：
console.time('parse large JSON');
const data = JSON.parse(largeString);
console.timeEnd('parse large JSON'); // 输出：parse large JSON: 124.345ms
// 或用 performance.now() 获取更高精度
const start = performance.now();
doHeavyWork();
console.log(`耗时: ${performance.now() - start}ms`);
⚠️ 注意：console.time 只适合粗粒度验证，不能替代 Performance 面板对调用栈、渲染影响、内存分配的全局分析。
不复杂但容易忽略：真正影响体验的，往往不是“总 JS 时间长”，而是“某一次脚本执行把主线程锁死 120ms”。Performance 面板帮你把这 120ms 拆开，看到里面到底发生了什么。
