监控宏任务执行时间需拆解为排队延迟（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 报告，基本可断定是主线程被占满所致
不复杂但容易忽略。
