long tasks api 仅如实记录主线程上已发生的≥50ms同步阻塞块，不统计累加或预测；须尽早注册performanceobserver监听'longtask'类型，结合attribution/name、performance.mark()打点及devtools调用栈定位源头，并以tbt、inp和帧率验证优化效果。
Long Tasks API 不是用来“计算”长任务的，而是浏览器自动捕获主线程上连续运行 ≥50ms 的同步执行块。它不统计、不累加、也不预测——只如实记录已发生的阻塞。诊断主线程阻塞，关键在于及时捕获、准确定位、结合上下文归因，而非单纯看 duration 数值。
尽早注册 PerformanceObserver 监听 longtask
监听必须在 内最靠前的位置启动，晚于 window.onload 就会漏掉首屏关键阻塞：
- 直接写在
<script></script>标签里，不加defer或async - 先检查兼容性：
'PerformanceObserver' in window && PerformanceObserver.supportedEntryTypes?.includes('longtask') - 监听类型严格为
'longtask'（不是'long-task'或'longTask'） - 回调中拿到的是
PerformanceLongTaskTiming实例，重点关注duration、startTime和attribution
区分“技术阻塞”和“用户感知卡顿”
≥50ms 是浏览器定义的长任务门槛，但人是否觉得卡，取决于发生时机：
- 后台标签页里的 200ms 任务几乎无感；点击按钮后 80ms 才响应，用户已明显察觉延迟
- 真正需预警的是：
duration ≥ 1000ms，或紧随click/input/scroll后发生的 ≥500ms 任务 - 连续多个短任务（如 20ms × 4）虽不被 Long Tasks API 记录，却可能造成帧丢失——需配合
performance.getEntriesByType('paint')或 Chrome DevTools 的 Flame Chart 分析
定位源头：从 attribution 到代码段
API 不提供函数名或堆栈，但能缩小排查范围：
-
attribution为空时（常见于跨域 iframe 或动态 import），退而依赖name字段，如'self'表示主文档 JS - 重点排查事件处理器内未节流的同步操作：input 中反复调用
getBoundingClientRect()、列表渲染前对万级数组做.map().filter().sort() - 第三方 SDK 的同步初始化逻辑（如统计脚本 DOM 遍历）常是隐藏源头，可用
attribution或name过滤排除 - 在可疑操作前后打点：
performance.mark('before-render')→ 执行 →performance.mark('after-render')→performance.measure()，再与长任务时间戳比对
验证优化是否生效
不能只看“有没有长任务”，要确认用户可感知的改善：
- 用
requestIdleCallback或setTimeout(..., 0)拆分 DOM 更新或数据处理，每次控制在 ≤16ms（≈1 帧） - 纯计算类逻辑移入 Web Worker，彻底剥离主线程
- 优化后观察 TBT（Total Blocking Time）、INP（Interaction to Next Paint）和实际帧率变化
- 线上上报需节流聚合：按 3 秒时间桶统计频次，附带
pathname、deviceMemory、isMobile等上下文，用navigator.sendBeacon()确保卸载时不丢数据
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
