监控主线程事件循环延迟需通过setTimeout、postMessage+MessageChannel或Long Tasks API间接测量：setTimeout(fn,0)估算宏任务排队时间，MessageChannel提供更稳定探测，Long Tasks API直接捕获≥50ms阻塞任务以归因分析。
监控浏览器主线程的事件循环延迟，核心是测量任务从被调度到实际执行之间的时间差。JavaScript 本身无法直接读取事件循环的内部时钟或队列状态，但可以通过精心设计的定时机制（如 setTimeout、postMessage、queueMicrotask 配合高精度时间戳）来间接估算主线程的排队延迟。
用 setTimeout(fn, 0) + performance.now() 估算宏任务延迟
setTimeout(fn, 0) 不会立即执行，而是将回调推入下一个宏任务队列；其实际执行时间与当前任务结束时刻的差值，可反映当时宏任务队列的积压程度。
- 在任务开始前记录
performance.now()时间戳t1 - 立即调用
setTimeout(() => { const t2 = performance.now(); console.log('宏任务延迟:', t2 - t1); }, 0) - 该差值越小（接近 0–1ms），说明队列空闲；若持续 > 5–10ms，表明主线程繁忙、存在延迟
- 注意：不能只测一次，需高频采样（如每秒 10 次）并统计 P95/P99 延迟，避免偶发抖动干扰判断
用 postMessage + MessageChannel 实现更稳定的微任务级探测
postMessage 触发的是宏任务，但配合 MessageChannel 的 port2 可构造“最轻量宏任务”，比 setTimeout 更少受浏览器优化影响，适合长期监控。
- 创建
const { port1, port2 } = new MessageChannel(); - 监听
port1.onmessage，在 handler 中计算延迟 - 每次想探测时，调用
port2.postMessage('')—— 这个消息会排队等待下一轮事件循环 - 对比
performance.now()在 post 前后与 handler 中的值，即可得到端到端延迟 - 优势：不依赖 timer 系统，不受
setTimeout最小间隔限制（4ms），稳定性更高
结合长任务（Long Tasks）API 获取真实阻塞信息
Chrome 和 Edge 支持 PerformanceObserver 监听 longtask 类型，直接捕获导致事件循环卡顿的长运行任务（≥ 50ms）。
立即学习“Java免费学习笔记（深入）”；
- 注册观察者：
new PerformanceObserver(cb).observe({ entryTypes: ['longtask'] }) - 每个
longtask条目包含startTime、duration、attribution（触发源，如 script、layout、paint） - 虽然不直接给出“延迟”，但持续出现 longtask 是事件循环延迟的根本原因，可用于归因分析
- 注意：需在页面早期初始化，否则可能错过首屏长任务
避免常见误区
单纯用 requestIdleCallback 或 performance.timeOrigin 无法准确反映事件循环延迟 —— 前者只在空闲时回调，后者是全局时间起点，不含队列等待信息。
- 不要依赖
Date.now()：精度低（毫秒级），且易受系统时间调整影响 - 避免在 DevTools 断点中测：断点会暂停整个 JS 执行，使结果完全失真
- 监控需区分场景：首屏加载期、用户交互高峰期、后台标签页等，延迟基线差异很大
- 移动端需额外关注：CPU 降频、后台标签节流（
setTimeout最小间隔可能升至 1000ms）
