如何利用 Performance API 定位长任务来源

Performance API 仅定位长任务发生位置而非具体代码行，需结合时间锚点、DevTools 调用栈和主动埋点三法映射到源码：用 PerformanceObserver 捕获 ≥50ms 任务，配合 performance.mark/measure 打标对齐，再通过 Chrome Performance 面板开启 Source Maps 查看 Call Stack，并在高风险逻辑中插入 User Timing 标记辅助归属。

Performance API 本身不提供长任务的函数调用栈，只告诉你“哪里卡了”，而不是“哪一行卡了”。要识别来源，必须结合时间锚点、DevTools 验证和主动埋点，把宽泛的 longtask 条目映射到具体代码段。

用 PerformanceObserver 捕获基础信息

这是生产环境监控的起点，必须放在 script 最前位置（不加 defer/async）：

• 检查兼容性：if ('PerformanceObserver' in window && PerformanceObserver.supportedEntryTypes?.includes('longtask'))
• 监听时过滤真正影响体验的条目：entry.duration > 50 是人眼可感知卡顿的阈值
• 每个 entry 包含 startTime、duration 和有限的 attribution（如脚本 URL 或 iframe 名），但没有函数名或行号

打时间标记，缩小排查范围

在用户操作或关键逻辑前后插入 performance.mark()，生成可对齐的时间锚点：

• 例如点击前：performance.mark('ui-action-start')；点击后：performance.mark('ui-action-end')
• 再用 performance.measure() 关联两标记，生成命名测量项
• 比对 longtask 的 startTime 是否落在该区间内，就能把任务归属到某次交互或某段逻辑

用 Chrome DevTools Performance 面板精确定位

这是补全调用栈的最可靠方式，需开启 Source Maps：

• 录制用户操作 → 在 Main 轨道中找宽度 ≥50ms 的黄色/红色色块（Chrome 自动标为 “Long Task”）
• 点击色块，在 Summary 面板查看 Call Stack，逐层展开即可看到你写的源码文件和行号
• 切换到 Bottom-up 标签页，按 “Total Time” 排序，排在最上面的函数往往是瓶颈根因

在高风险代码中主动埋点验证

对易引发长任务的操作做轻量级包裹，让耗时出现在 User Timing 轨道里，与 longtask 时间对齐：

• 渲染大数据列表：console.time('render-1000-items') / console.timeEnd('render-1000-items')
• 解析大 JSON：performance.mark('parse-json-start') → 解析后 performance.mark('parse-json-end')
• 这些标记会显示在 Performance 面板的 User Timing 轨道，和 longtask 时间戳一对照，归属一目了然