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 时间戳一对照，归属一目了然
