Long Tasks API仅记录≥50ms主线程同步执行块，需主动以≥1000ms为卡顿强信号并结合操作时间戳或帧率验证；必须用PerformanceObserver在<head>中尽早监听longtask类型，支持性需检测且不可拼错；attribution为空时依赖name字段；getEntriesByType仅用于调试快照；Safari不支持需降级；上报须节流聚合并携带上下文，且API本身不揭示忙的原因，需配合DevTools深度分析。
Long Tasks API 不能直接告诉你“页面卡了”，它只忠实地记录 ≥50ms 的主线程同步执行块；真要定位用户感知的卡顿，得靠你主动把 duration >= 1000 当作强信号，并结合操作时间戳或帧率数据交叉验证。
用 PerformanceObserver 实时捕获 longtask 条目
这是唯一能在线上环境持续监听、不漏掉首屏关键任务的方式。必须在 <head> 里尽早注册，晚于 window.onload 就可能错过渲染初期的长任务。
- 检查支持性：
'PerformanceObserver' in window && PerformanceObserver.supportedEntryTypes?.includes('longtask') - 监听类型必须是
'longtask'（不是'long-task'或'longTask'） - 回调中拿到的是
PerformanceLongTaskTiming实例，重点看duration、startTime和attribution -
attribution在跨域 iframe 或动态import()脚本里常为空，此时只能靠name字段粗判来源（如'self'表示主文档 JS）
用 performance.getEntriesByType('longtask') 快速调试已发生任务
适合在 DevTools 控制台手动查当前页积累的长任务，但它不监听后续行为，纯属“快照式”回溯。
- 放在
window.onload后调用，能覆盖大部分渲染阶段任务；但若放在setTimeout(() => {}, 0)里，可能漏掉 microtask 清空后立刻触发的 long task - 返回数组按
startTime升序排列，但浏览器可能因内存策略丢弃旧条目，不保证连续 - 字段同上，但没有实时性——无法用于埋点上报，仅限本地分析
为什么 duration ≥ 50ms 不等于卡顿？
RAIL 模型说“50ms 内响应输入”，但人是否觉得卡，取决于上下文：后台标签页里的 200ms 任务没人会察觉，而点击按钮后 80ms 才反馈，用户已经皱眉了。
立即学习“前端免费学习笔记（深入）”；
- 真正值得报警的，是
duration >= 1000的任务，或紧随用户操作（如click、input）之后发生的 ≥500ms 任务 - 连续多个短任务（比如 20ms × 3）也可能导致帧丢失，但 Long Tasks API 不记录它们——得靠
performance.getEntriesByType('paint')或chrome://tracing查 Flame Chart - Safari 完全不支持该 API，线上方案必须降级（例如 fallback 到自定义
performance.mark()+measure()手动打点）
生产环境上报要注意节流和归因
高频上报 long task 本身就会加重主线程负担，且原始数据缺乏上下文，难以定位业务模块。
- 开发期可全量
console.warn()；上线后建议每 30 秒聚合一次，用navigator.sendBeacon()发送，确保卸载前不丢数据 - 过滤已知稳定的第三方脚本（比如统计 SDK 的
track()），聚焦自身业务逻辑中的高频长任务 - 别只报
duration：带上document.visibilityState、performance.now() - entry.startTime（相对页面启动时间）、以及最近一次用户操作类型（如'search-submit'）
最容易被忽略的一点：Long Tasks API 只反映主线程“忙了多久”，不说明“忙什么”。哪怕你看到 attribution 是某个脚本 URL，也得配合 Chrome DevTools 的 Performance 面板录制复现流程，才能确认是函数调用栈深、还是强制同步布局（layout thrashing）拖垮了性能。
