performance.getEntriesByType('longtask')可获取已结束的超50ms主线程任务，但无调用栈；需结合performance.mark()/measure()打时间锚点，并与longtask时间戳对齐，再通过DevTools验证定位阻塞源头。
直接用 performance.getEntriesByType('longtask') 可以快速拿到已发生的长任务列表，但它本身不带调用栈，无法直接定位是哪段 JS 触发的。要识别真正阻塞渲染管线的源头，得结合时间戳对齐、上下文标记和 DevTools 验证三步走。
获取并筛选 longtask 基础数据
该 API 返回的是浏览器已记录的、执行超 50ms 的主线程任务（含脚本执行、解析、编译、事件回调等）：
- 调用
performance.getEntriesByType('longtask')获取全部历史 longtask 记录 - 按
startTime和duration排序，优先关注最近、持续时间最长（如 >100ms）或高频出现（同一操作反复触发）的任务 - 注意：该方法只返回已结束的任务，无法捕获正在运行中但尚未完成的长任务
用 User Timing 标记关键代码段做时间锚点
单纯看 longtask 时间范围太宽泛，必须把 JS 执行逻辑“打上时间戳”，才能匹配到具体函数：
- 在可疑逻辑前后插入
performance.mark()，例如：performance.mark('fetch-and-render-start');<br>await fetchData();<br>renderList(data);<br>performance.mark('fetch-and-render-end'); - 再用
performance.measure()关联两标记，生成可检索的测量项 - 后续对比
longtask.startTime与各measure.startTime，若时间重叠度高（误差
关联调用栈需依赖 PerformanceObserver + source map
getEntriesByType 不提供堆栈，但 PerformanceObserver 在监听时可配合错误捕获或手动注入上下文：
- 启用 observer 监听
longtask类型，收到 entry 后立即触发console.trace()（虽非精确栈，但能暴露当前执行上下文） - 在构建流程中保留 source map，并在 DevTools Performance 面板中录制真实用户操作——面板会显示每个长任务的完整调用栈，点击即可跳转源码行
- 对第三方 SDK 或框架内任务，可通过
entry.name字段判断来源（如"setTimeout"、"promiseRejection"、"event:click"），缩小排查范围
验证是否真影响渲染管线
不是所有 longtask 都导致卡顿，关键要看它是否发生在关键帧窗口（如 rAF 回调前后）或阻塞输入响应：
- 检查 longtask 是否落在 FCP（首次内容绘制）或 LCP（最大内容绘制）之前——这类任务大概率拖慢首屏
- 用
performance.getEntriesByType('paint')拿到绘制时间点，比对 longtask 是否紧邻first-paint或造成帧间隔突增（如某帧耗时从 12ms 跳到 80ms） - 观察是否存在连续多个 longtask（即“长任务链”），这往往意味着未拆分的批量 DOM 操作或递归计算
