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” 排序，排在最上面的函数往往是瓶颈根因
这一步才是真正定位到代码行的关键。Performance 面板的 Call Stack 能还原出完整的执行路径，配合 Source Maps，你看到的不是压缩后的代码，而是你亲手写的源码，审查起来非常直观。
在高风险代码中主动埋点验证
对易引发长任务的操作做轻量级包裹，让耗时出现在 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 时间戳一对照，归属一目了然
主动埋点相当于给高风险逻辑装上了“监控探头”，它和 PerformanceObserver 捕获的 longtask 条目相互印证，能帮你确认到底哪段代码是真正的罪魁祸首。
