排查JavaScript长任务卡顿，核心是定位主线程连续执行超50ms的代码块；需用Performance面板抓取长任务、PerformanceObserver主动监听，并结合调用栈判断卡顿类型，最后量化验证优化效果。
排查 JavaScript 中的长任务卡顿，核心是定位主线程上连续执行超 50ms 的代码块——它直接挤占渲染和响应时间，造成用户可感知的卡顿。不用猜、不靠感觉，用浏览器原生工具+代码监控双路径验证。
用 Performance 面板直观抓取长任务
打开 Chrome DevTools → Performance 标签 → 点击录制（●）→ 模拟用户真实操作（如点击、滚动、加载）→ 停止录制。重点关注：
- Main 轨道：找宽度 ≥50ms 的黄色/红色长条色块，鼠标悬停能看到耗时、调用栈和具体源码行号
- Summary 面板→ Tasks 分类：筛选 Duration > 50ms 的条目，点击可跳转到对应时间轴位置
- Call Tree 标签：按 Total Time 排序函数，快速锁定“高耗时源头”，比如未节流的 resize 处理器、同步遍历大量 DOM 的循环
用 PerformanceObserver 主动监听长任务
在页面中嵌入轻量级监控代码，把长任务变成可上报、可统计的数据点：
- 创建 observer 监听
longtask类型，捕获每个长任务的duration、startTime和attribution - 通过
entry.name判断来源（self是当前页，iframe或第三方脚本可被识别） - 生产环境建议节流上报，例如每分钟最多上报 3 条，避免监控本身拖慢性能
结合调用栈判断卡顿类型
不是所有长任务都来自 JS 执行。Performance 面板里看到的长色块，要结合上下文判断本质：
立即学习“Java免费学习笔记（深入）”；
- 若调用栈含
getBoundingClientRect()、offsetTop、clientWidth等，大概率是强制同步布局（layout thrashing） - 若集中在样式计算阶段（Layout 阶段耗时高），可能是 CSS 选择器太复杂或频繁修改 class
- 若出现在 Parse HTML 或 Style 轨道，说明问题不在 JS，而是 HTML 结构或 CSSOM 构建慢
验证优化是否真正生效
改完代码不能只看“好像不卡了”，要量化对比：
- 用同一操作路径重新录制 Performance，对比火焰图中 Main 轨道的长色块数量和总时长
- 检查优化后长任务是否从 120ms 降到 40ms 以内，或拆分为多个 ≤50ms 的微任务
- 配合
requestAnimationFrame或queueMicrotask拆分逻辑后，观察帧率是否稳定在 60fps
