Long Task指主线程连续执行超50ms的JavaScript任务，直接导致卡顿；在Performance面板中通过Main轨道色块、Summary筛选和Call Tree调用栈定位，并支持启用高亮与CPU节流辅助识别。
Long Task 直接阻塞主线程，超过 50ms 就会让用户感知卡顿——这不是理论阈值，而是浏览器强制标记、Chrome Performance 面板默认高亮的硬性标准。
怎么在 Performance 面板里一眼揪出 Long Task
打开 Chrome DevTools → Performance 标签 → 点击录制按钮（●），复现操作（比如点击加载按钮或滚动列表）→ 停止录制。关键看三个地方：
- Main 轨道中宽度 ≥50ms 的连续色块（常带红色三角警告图标），鼠标悬停能看到
Duration和调用栈 - Summary 面板下展开
Tasks，筛选Duration > 50ms的条目，点击可跳转到对应时间轴位置 - Call Tree 标签按
Total Time排序，排在最上面的函数大概率就是源头，比如renderAllFilters或updateTableData
注意：如果没看到红色标记，检查右上角齿轮图标 → 勾选 Enable long task highlighting；CPU 节流（如 4x slower）能放大问题，但不是必须步骤。
为什么 performance.getEntriesByType('longtask') 返回为空
这个 API 只捕获已发生的 long task，且有严格前提：
立即学习“前端免费学习笔记（深入）”；
- 页面需启用
PerformanceObserver监听，或在 long task 发生后立即调用（不能等页面 onload 之后才查） - 若页面用的是 iframe 加载逻辑，
name字段可能为same-origin-ancestor或cross-origin-descendent，主文档里查不到 - 某些同步 XHR、强制 layout（如反复读
offsetTop）触发的长任务，可能归类为rendering类型而非script，getEntriesByType('longtask')仍能捕获，但 attribution 字段可能为空
更稳妥的做法是结合 PerformanceObserver 实时监听：
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
if (entry.duration >= 50) {
console.log('Long Task detected:', entry.startTime, entry.duration);
}
});
});
observer.observe({ entryTypes: ['longtask'] });
DOM 操作密集导致的 Long Task 怎么定位
这类问题不会直接显示“DOM”字样，但火焰图里会出现大量 Recalculate Style、Layout、Update Layer Tree 子任务，父级常是某个事件回调（如 scroll 或 input 处理函数）。典型线索包括：
- 调用栈里频繁出现
getBoundingClientRect、offsetHeight、clientWidth等读取布局的 API - 同一函数内交替执行读 DOM（触发回流）和写 DOM（触发重绘），形成 layout thrashing
- 批量插入 1000+ 元素时用了
innerHTML或循环appendChild，没用DocumentFragment
验证方式：在 Performance 录制中切换到 “Bottom-up” 视图，按 Self Time 排序，找耗时集中在 Layout 或 Paint 上游的 JS 函数。
容易被忽略的跨上下文 Long Task
qiankun、iframe 或 Web Worker 并不隔离主线程阻塞——子应用或 iframe 里的 JS 仍跑在同一个渲染进程主线程上。如果你发现：
- 主应用没明显长任务，但整体卡顿严重
- Performance 中 Main 轨道某段长任务的
name是same-origin-descendent或cross-origin-unreachable - Call Tree 里函数名显示为
unknown或来源路径指向第三方 SDK
那大概率是子应用或广告脚本在后台偷偷执行了同步循环或未节流的 resize 监听器。这时候得去子应用代码里查 requestIdleCallback 是否被滥用，或者用 attribution 字段反向定位容器 frame。
