主线程卡顿需用chrome devtools performance面板实测：录制真实操作，聚焦main线程中>50ms的红色long task，通过调用栈定位scroll/mousemove等高频回调，检查强制同步布局、密集计算及闭包创建问题，并结合scripting占比与memory快照交叉验证。
主线程繁忙，最直接的表现是页面卡顿、响应延迟、动画掉帧。要锁定具体是哪个函数在高频拖慢主线程，不能靠猜，得用 Chrome DevTools 的 Performance 面板做实测抓取，再结合关键指标和调用栈层层下钻。
录制一次真实用户操作
打开 DevTools → Performance 标签 → 确保勾选 “Screenshots” 和 “Disable cache” → 点击录制圆点 → 在页面上复现卡顿场景（比如快速滚动、连续点击按钮、输入搜索词）→ 3–5 秒内停止录制。这一步必须模拟真实交互，静态代码扫描无法反映运行时压力。
聚焦 Main 线程火焰图中的红色长条
录制结束后，重点看下方的 Main 线程时间轴：
- 红色块 >50ms 就是 Long Task，代表主线程被独占太久，UI 无法响应
- 横向拖动找重复密集出现的红色块（比如每滚动一下就冒出一个），这类函数大概率是 scroll/mousemove/input 的回调
- 点击某个红色块，右侧 Details 面板会显示完整调用栈、执行耗时、触发事件类型（如 Event:scroll）、涉及 DOM 元素数量
顺藤摸瓜查源头函数
在 Details 面板中，从最顶层（顶部）开始往下看调用链，重点关注：
- 是否由事件监听器直接触发（如 EventListener.handleEvent）
- 是否调用了强制同步布局的 API（offsetTop、getBoundingClientRect、clientWidth、scrollHeight）——这类调用一旦出现在循环或高频回调里，就会反复触发回流
- 是否有大量计算逻辑嵌套在回调中（如数组遍历、JSON.parse、正则匹配）
- 是否在每次调用中新建闭包或绑定函数（如 el.addEventListener('click', () => {...}) 写在循环里）
交叉验证内存与脚本执行占比
回到 Summary 标签页，观察饼图分布：
- 若 Scripting 占比显著偏高（>40%），且 Main 线程中函数堆叠密集，说明 JS 执行确实是瓶颈，不是渲染或网络问题
- 配合 Memory 面板拍两个堆快照（操作前/后），看是否有 Detached DOM 节点持续增长，或某类对象实例数飙升——这可能意味着高频函数在不断创建未释放的对象
