最直接有效的定位方式是用 Chrome DevTools Performance 面板录制并分析 Call Tree，按 Self Time 降序排序，聚焦“Main”线程中自身耗时高、反复出现的函数，识别渲染密集型操作、未节流回调、大数据遍历或重型第三方方法，再通过注释验证和轻量替代优化。
主线程脚本执行耗时过高，最直接有效的定位方式就是用 Chrome DevTools 的 Performance 面板录制并分析 Call Tree。它能清晰展示函数调用层级、各自耗时和占比，帮你快速揪出真正拖慢页面的“罪魁祸首”。
一、先录一段真实的用户操作
打开 DevTools → Performance 标签 → 点击左上角录制按钮（●），然后在页面上复现卡顿场景（比如点击按钮、滚动、加载数据），持续 2–5 秒后停止录制。确保勾选了 JavaScript samples（默认开启），否则 Call Tree 里看不到 JS 函数细节。
二、聚焦 Call Tree，按“Self Time”降序排序
录制结束后，下方切换到 Bottom-Up 或直接看 Call Tree 标签页。默认按 Total Time 排序，但真正关键的是 Self Time（自身执行时间，不含子调用）：
- Self Time 高 → 这个函数本身做了大量计算，比如长循环、复杂正则、未优化的 JSON.parse/JSON.stringify
- Total Time 高但 Self Time 低 → 问题在其子调用，要继续展开看下层
- 留意顶部显示的 “Main” 线程，所有 JS 执行都归在这里，避免被 Worker 或 Timer 分散注意力
三、识别典型“高危模式”，结合源码定位
Call Tree 中反复出现且 Self Time 突出的函数，往往对应以下几类问题：
-
渲染密集型操作：比如在 for 循环里反复读写
offsetHeight、getComputedStyle，触发强制同步布局（Layout Thrashing） -
高频回调未节流：scroll、input、resize 回调没加
throttle或debounce，导致每帧执行多次 -
大数据结构遍历/深拷贝：如对上万条数据调用
Array.map().filter().sort()链式调用，或滥用JSON.parse(JSON.stringify(obj)) -
第三方库重型方法：比如 moment.js 的
format()、Lodash 的cloneDeep()在循环中被频繁调用
四、验证与优化：改一行，再录一次
找到嫌疑函数后，别急着重写逻辑。先做最小验证：
- 临时注释掉该函数调用，重新录制，看主线程耗时是否明显下降
- 用
console.time('xxx')在函数头尾打点，确认 DevTools 数据是否一致 - 尝试轻量替代：用
requestIdleCallback拆分任务，用documentFragment批量 DOM 操作，用Intl.NumberFormat替 moment 格式化等
Call Tree 不是魔法，但它把“谁在吃时间”这件事变得非常诚实。盯紧 Self Time，顺藤摸瓜展开子节点，比盲猜 console.log 或靠经验排查快得多。
