先记住这个答案
先把请求耗时拆成排队、应用处理和外部依赖，再结合事件循环延迟与 CPU 证据判断。monitorEventLoopDelay 可通过定时采样观察循环延迟，指标以纳秒表示，展示毫秒时要换算；它提示调度被延误，但不能直接指出是哪一个函数，也不能单独区分同步计算、GC 或系统调度压力。若延迟升高，应在相同时间窗口采集 CPU profile 并关联请求路径；若循环仍及时而下游等待很长，则应继续查依赖与队列。
- 循环延迟不是具体函数的定位结果
- 直方图纳秒值展示前需要换算
- 请求链路、CPU 和延迟应按同一窗口关联
先把不同类型的等待分开
同步 JSON 处理、复杂正则、大循环或同步外部命令可能长期占用当前线程。数据库或远端接口慢则可能主要让某个请求等待，事件循环仍能处理其他请求；两种情况需要不同修复手段。
GC、CPU 资源竞争和调度抖动也会影响循环延迟。看到一个高峰后，应关联对应时间段的负载和调用栈，不能只因为某个函数看起来复杂就直接认定它是根因。
记录分布并正确处理单位和窗口
下面建立延迟直方图，按窗口报告高分位和最大值，并在报告后重置。没有样本时不输出伪造的有效数字，停止监测时同时清理定时器与采样器，避免留下不需要的后台工作。
report 应交给轻量、可控的指标适配器，不应同步写大量日志或执行昂贵序列化。示例中的 unref 让报告定时器不单独保持进程存活，不表示监测已经覆盖退出后的时间。
import { monitorEventLoopDelay } from 'node:perf_hooks';
export function observeDelay(
report: (sample: { p99Ms: number; maxMs: number }) => void,
intervalMs = 1000
) {
const histogram = monitorEventLoopDelay({ resolution: 10 });
histogram.enable();
const timer = setInterval(() => {
if (histogram.count === 0) return;
report({ p99Ms: histogram.percentile(99) / 1e6, maxMs: histogram.max / 1e6 });
histogram.reset();
}, intervalMs);
timer.unref();
return () => { clearInterval(timer); histogram.disable(); };
}这里将纳秒除以一百万得到毫秒，统计的是窗口内观察值。验证可以在独立测试进程中制造短暂同步占用，确认峰值升高；不能在正在服务用户的进程中随意注入忙循环。
确认根因后再选择优化方向
若 CPU 栈集中在一段同步处理，先评估输入上限、算法复杂度和是否能减少重复计算，再考虑切片或卸载。只把函数改成 async 不会改变其中同步代码占用线程的事实。
修复后应复测相同数据规模与并发，确认循环延迟和用户请求都改善，并观察内存及错误率。仅把工作搬到无限队列中可能让主线程看起来轻松，却把问题变成排队延迟和资源积压。
容易答错的地方
- 把纳秒直接当毫秒展示
- 这会把指标放大很多数量级，导致错误告警和误判。应核对 API 单位并在展示层明确换算，同时记录窗口与分位数，避免不同单位的指标在同一图表中被直接比较。
- 只看 CPU 百分比就排除循环阻塞
- 短时尖峰可能被平均值掩盖，单线程占用也可能在多核总体指标里不显眼。应结合事件循环延迟分布和具体线程调用栈，并关联请求时间线，不能用一个汇总百分比结束排查。
面试官还会怎么问？
event loop utilization 高就一定是坏事吗？
不一定，它描述循环活动程度，需要结合吞吐、延迟和工作性质解释。持续高活动且响应变差可能值得调查，但一个指标不能直接判断用户体验，也不能替代对 CPU 栈和外部等待的分析。
采样间隔越小越准确吗？
更细采样可能提高观察粒度，也会增加开销，仍不能直接定位函数。应选择与问题时间尺度相符的配置，并用代表性负载验证监测影响，避免让监控本身成为额外负担。
修复同步阻塞后请求仍慢怎么办？
继续拆分等待来源，检查下游耗时、连接池和任务队列。循环恢复及时只解决其中一类瓶颈，不能保证所有端到端延迟都消失；应沿同一请求时间线逐段验证。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。