performance.getEntries()无法识别长任务，因其默认不返回longtask类型条目；必须调用performance.getEntriesByType('longtask')才能获取已发生的长任务记录，因长任务仅在主线程阻塞超50ms后延迟生成且需按类型主动查询。
直接用 performance.getEntries() 无法识别长任务，因为该方法默认不返回 longtask 类型条目。必须显式调用 performance.getEntriesByType('longtask') 才能获取已发生的长任务记录。
为什么 getEntries() 不行，而 getEntriesByType('longtask') 可以
performance.getEntries() 返回的是当前已收集的所有性能条目，但浏览器只在满足特定条件时才生成 longtask 条目——主线程连续执行 JavaScript 超过 50ms，且该任务未被中断。这类条目不会混在通用列表中，必须按类型主动查询。
- 长任务是延迟生成的：只有任务实际结束、浏览器确认阻塞超限时，才会创建对应条目
- 默认不包含在 getEntries() 结果里：它只包含 navigation、resource、paint、mark 等显式触发的类型
- 必须指定类型：
performance.getEntriesByType('longtask')是唯一能批量读取已有长任务的方式
如何用 getEntriesByType('longtask') 检测渲染阻塞
该方法适合在页面空闲或错误捕获阶段做快照分析，例如在用户交互后、路由切换完成时检查是否刚发生长任务：
- 立即调用可获取到此前已触发的长任务（如首屏加载、滚动后、点击后）
- 每个条目含
startTime和duration，结合时间戳可判断是否与关键渲染节点重叠（比如发生在 first-contentful-paint 之后 200ms 内） - 若
duration > 50且startTime接近用户操作时间（如click事件时间），基本可判定该任务干扰了响应或渲染
示例代码：
<!-- 在关键交互后检查 -->document.getElementById('submit-btn').addEventListener('click', () => {<br> setTimeout(() => {<br> const tasks = performance.getEntriesByType('longtask');<br> tasks.forEach(t => {<br> if (t.duration > 50 && t.startTime > Date.now() - 1000) {<br> console.warn('疑似阻塞渲染的长任务:', t.duration, 'ms');<br> }<br> });<br> }, 0);<br>});
配合其他 API 定位渲染影响范围
单靠 longtask 条目无法知道它是否真正阻塞了渲染，需交叉验证：
- 查
performance.getEntriesByType('paint')：对比first-contentful-paint或largest-contentful-paint时间，若长任务startTime + duration覆盖了 paint 时间点，说明它拖慢了首屏或主要内容呈现 - 查
performance.getEntriesByType('navigation')：确认长任务是否集中在domContentLoadedEventEnd到loadEventEnd之间，这是常见渲染瓶颈区间 - 查
performance.getEntriesByType('resource')：若某资源加载完成后立刻出现长任务，可能是其回调函数（如解析 JSON、初始化组件）引发的
注意局限性和补充手段
getEntriesByType('longtask') 是静态快照，不能替代持续监控：
- 它只能读取已发生的任务，无法捕获后续新出现的长任务
- 主页面中
name字段通常为空，attribution不稳定，难以精确定位代码位置 - 推荐搭配
PerformanceObserver长期监听，用于生产环境实时捕获；getEntriesByType更适合调试、自动化测试或异常现场快照
