2. Node.js运行时与事件循环

Node.js 的运行时并不是“多线程处理请求”的模型，而是以单线程 JavaScript 执行为核心，把耗时的 I/O 操作交给底层 libuv 线程池或操作系统异步接口，再通过事件循环把完成结果回调回主线程。理解这条主线，才能解释为什么一段看似普通的同步代码会拖垮整个服务，也能解释为什么同样的接口在压测中会出现“CPU 不高但延迟很高”的现象。

非阻塞 I/O 与事件驱动的基本分工

当 Node.js 执行 fs.readFile、net.Socket 读写或数据库驱动发起网络请求时，JavaScript 主线程并不会等待磁盘或网络返回，而是把任务注册到 libuv，然后继续执行后续同步代码。libuv 根据任务类型选择不同通道：文件系统、DNS 查询等通常进入线程池；TCP 连接、定时器等则更多依赖操作系统的事件通知机制。任务完成后，回调被放入事件循环的相应队列，等待主线程空闲时执行。

因此，Node.js 的“非阻塞”并不是所有操作都非阻塞，而是指 JavaScript 主线程不被 I/O 等待占用。真正阻塞主线程的是同步 CPU 计算、同步文件读取、JSON.parse 超大字符串、复杂正则回溯、加密解密等。企业级服务中，最常见的性能事故不是 I/O 慢，而是主线程被一段同步逻辑占住，导致所有已就绪的回调无法及时执行。

宏任务与微任务的执行顺序

事件循环的每个阶段处理的是宏任务，例如定时器回调、I/O 回调、setImmediate。而 process.nextTick 和 Promise 回调属于微任务，它们不在事件循环的六个阶段中排队，而是在每个宏任务执行完成后、进入下一个阶段之前被清空。这意味着微任务具有更高的执行优先级，也意味着如果微任务中不断产生新的微任务，事件循环会被“卡”在当前阶段，无法推进到 timers 或 poll。

下面这段代码可以直观看出顺序差异：

setTimeout(() => console.log('timeout'), 0);
setImmediate(() => console.log('immediate'));

Promise.resolve().then(() => console.log('promise'));
process.nextTick(() => console.log('nextTick'));

console.log('sync');

在 Node.js 中，典型输出为：sync、nextTick、promise、timeout、immediate。其中 timeout 与 immediate 的先后顺序受当前事件循环所处阶段影响，并非绝对固定；但 nextTick 和 Promise 微任务一定先于定时器和 I/O 宏任务执行。企业级代码中，如果在 nextTick 里递归调用自身，就会造成事件循环饥饿，表现为接口全部超时但 CPU 占用并不一定很高。

企业级性能影响与观测手段

在高并发 API 服务中，事件循环延迟是比 CPU 使用率更敏感的健康指标。一个请求如果同步执行 80ms 的复杂计算，在这 80ms 内所有其他请求的回调都无法执行，P99 延迟会被直接抬高。常见的性能退化来源包括：在请求处理链路中同步读取配置或模板文件、使用 JSON.parse 解析几十 MB 的响应体、在循环中执行同步加密、使用灾难性回溯的正则表达式、以及把大量数据一次性放入内存排序。

观测事件循环延迟可以用 perf_hooks 的 monitorEventLoopDelay：

const { monitorEventLoopDelay } = require('perf_hooks');
const h = monitorEventLoopDelay({ resolution: 20 });
h.enable();

setInterval(() => {
  console.log('event loop delay p99(ms):', (h.percentile(99) / 1e6).toFixed(2));
}, 5000);

如果 p99 持续超过 50ms，就应排查同步阻塞点。另一个实用手段是记录请求处理前后的 process.hrtime.bigint()，对比“业务逻辑耗时”与“事件循环等待耗时”。当业务逻辑本身很快，但请求总耗时很高，通常说明主线程被其他任务占用。

把 CPU 密集任务移出主线程

对于无法避免的 CPU 密集任务，企业级方案不是“优化到不阻塞”，而是把它移出主线程。可选路径包括：使用 worker_threads 把计算放入独立线程；把图像处理、压缩、加密等交给独立服务；使用子进程执行一次性重任务；或者用原生插件在 libuv 线程池中执行。选择依据是任务频率、数据量、通信成本和部署复杂度。

以 worker_threads 为例，主线程只负责接收请求和转发数据，worker 完成计算后通过消息返回结果。这样事件循环可以继续处理其他请求，P99 延迟不会被单个重任务拖垮。需要注意的是，worker 之间传递大对象会产生序列化成本，适合传递结构化数据或 ArrayBuffer 转移所有权。

常见误区与排障方向

第一个误区是认为“Node.js 单线程所以不能利用多核”。实际上可以通过 cluster 或容器多副本利用多核，但每个进程内部仍然是单线程事件循环。第二个误区是认为“异步一定比同步快”。异步的价值在于不阻塞主线程，而不是降低单次操作延迟；对于小文件读取，同步读取有时反而更快，但它会阻塞其他请求。第三个误区是忽视微任务饥饿，认为只要用了 Promise 就是异步安全。

排障时可按以下顺序定位：先看事件循环延迟是否异常；再看是否有同步文件、同步加密、大 JSON 解析；然后检查 nextTick 或 Promise 递归；最后用 --prof 或 --cpu-prof 生成 CPU profile，确认热点函数。若热点在业务代码中，优先拆分或迁移；若热点在依赖库中，考虑替换库或放入 worker。

理解事件循环的最终目的，是让开发者能判断一段代码到底运行在哪个阶段、会阻塞谁、影响哪些请求。只有把“非阻塞 I/O”“宏任务与微任务”“事件循环延迟”放进同一个运行时模型中，才能在企业级 Node.js 服务中做出正确的性能取舍。