监控宏任务执行时间需拆解为排队延迟（queueTime到startTime）和纯执行耗时（workStart到workEnd）；前者反映事件循环拥堵，后者体现逻辑性能瓶颈；配合PerformanceObserver捕获longtask可交叉验证主线程阻塞原因。

要监控宏任务在事件循环中的执行时间，关键不是只看“它花了多久”，而是拆解两个阶段：从调度到开始执行的排队延迟，以及回调函数内部实际运行的纯执行耗时。两者叠加才是用户感知的总延迟，但分开测量才能准确定位瓶颈是卡在调度（主线程忙）还是卡在计算本身（逻辑太重）。

在调度点打点：捕获入队时刻

宏任务（如 setTimeout、setInterval、事件回调、fetch 成功回调）被创建或触发的瞬间，就是它进入宏任务队列的起点。这时用 performance.now() 记录时间戳：

• const queueTime = performance.now();
• setTimeout(() => { /* 回调 */ }, 0); —— 注意：打点必须在 setTimeout 调用前，不是延时参数里
• 对 click 等事件监听器，打点放在事件处理器注册后、首次触发前（或在事件回调内用 event.timeStamp 辅助校准）

在执行入口打点：捕获真正开始时刻

回调函数第一行就再次调用 performance.now()，得到它实际被执行的时间：

• setTimeout(() => {
•   const startTime = performance.now(); // 这里是“开始执行”的精确时刻
•   // 后续业务逻辑...
• }, 0);

用 startTime - queueTime 就是「排队延迟」——反映事件循环拥堵程度。如果这个值持续 > 50ms，说明主线程长期被占用，可能有长任务或密集计算阻塞了调度。

再嵌套一次打点：分离纯执行耗时

仅知道“何时开始”还不够。需进一步测量回调内部逻辑本身花了多久：

• setTimeout(() => {
•   const startTime = performance.now();
•   const workStart = performance.now();
•   doHeavyWork(); // 你的实际业务
•   const workEnd = performance.now();
•   console.log('执行耗时:', workEnd - workStart);
•   console.log('排队耗时:', startTime - queueTime - (workEnd - workStart));
• }, 0);

这样就能明确区分：是宏任务一直排不上队（排队耗时高），还是队一排上就开始猛算（执行耗时高）。前者优化方向是拆分任务、移入 Web Worker；后者则聚焦算法、减少 DOM 操作或缓存计算结果。

配合 PerformanceObserver 捕获长任务

浏览器提供 PerformanceObserver 监听 longtask 类型，可自动捕获主线程连续执行 > 50ms 的任务块。虽然它不直接标记某个 setTimeout，但它能告诉你“哪段时间主线程被锁死”，从而反向验证你测出的排队延迟是否合理：

• 启用监听：new PerformanceObserver(cb).observe({entryTypes: ['longtask']})
• 结合你手动打点的数据，若某次 queueTime → startTime 差值大，且同期有 longtask 报告，基本可断定是主线程被占满所致

不复杂但容易忽略。