避免阻塞事件循环的常见场景

事件循环是 Node.js 单线程模型的心脏，它的健康状况直接决定了服务的响应速度和吞吐量。一旦某个同步操作长时间占用主线程，事件循环就会被阻塞，所有新来的请求、定时任务、甚至已经完成的 I/O 回调都无法及时执行，具体表现就是接口延迟飙升、连接超时，甚至整个服务假死。

这一节将梳理日常开发中最容易让事件循环陷入阻塞的场景，并给出可落地的优化方案。理解这些场景，能帮助我们在写出功能代码的同时，也具备“不拖垮主线程”的意识。

1. 同步读取大文件或执行大量磁盘 I/O

fs.readFileSync、fs.writeFileSync 等同步 API 在执行时会直接阻塞事件循环，直到磁盘操作完成。对于小配置文件，影响可以忽略；但如果用它们处理几百 MB 的日志文件或上传文件，主线程会停顿数秒甚至更长。

错误示范：

// 每次请求都同步读取整个文件，并发一高服务直接卡死
app.get('/log', (req, res) => {
  const data = fs.readFileSync('/var/log/huge.log', 'utf8');
  res.end(data);
});

正确做法：

使用异步 API（fs.readFile + Promise）或流式处理，避免在某一个请求上“堵死”。
如果必须处理大文件，优先用 Stream 边读边写，既能避免阻塞，又能控制内存占用。

app.get('/log', (req, res) => {
  const stream = fs.createReadStream('/var/log/huge.log', 'utf8');
  stream.pipe(res);
});

2. 复杂的正则表达式处理长文本

正则表达式本身是同步的，当模式复杂（特别是包含回溯的组合）且处理的字符串很长时，执行时间可能呈指数增长，瞬间拖住整个主线程。

典型问题：

用用户输入拼接正则（ReDoS 攻击风险）。
在请求处理器中直接对大型 HTML/XML/JSON 文本执行复杂正则。

优化手段：

限制正则引擎的回溯深度，改用安全的正则库（如 re2）。
将文本分段处理，每处理一段就给事件循环一个喘息的机会。
将正则匹配任务交给 worker_threads 在后台线程执行，主线程只收发结果。

3. 大量同步计算：循环、递归与数学运算

一个简单的 for 循环如果迭代次数足够多，或者内部执行了较重的运算（如加密哈希、大数计算），就会把事件循环霸占住。这类问题在业务代码中并不罕见，比如对十万条数据做字段转换，或者计算报表多维聚合。

识别特征：

// 处理十万条数据，主线程被占用数百毫秒
function syncProcess(items) {
  return items.map(item => {
    // 一些复杂的计算
    return heavyTransform(item);
  });
}

解决思路：

任务拆分：用 setImmediate 或 process.nextTick 将循环拆分成多个批次，每批处理一定数量数据后交出控制权。
使用 worker_threads：把计算密集的任务整体移到 Worker 线程，主线程继续处理 I/O。

拆分示例（分批处理数组）：

async function processInBatches(items, batchSize, fn) {
  for (let i = 0; i < items.length; i += batchSize) {
    const batch = items.slice(i, i + batchSize);
    batch.forEach(fn);
    // 每处理一批，让出主线程，允许处理其他任务
    await new Promise(resolve => setImmediate(resolve));
  }
}

4. 超大 JSON 的序列化与反序列化

JSON.parse 和 JSON.stringify 是同步方法，如果在主线程处理一个上百 MB 的 JSON 字符串，会导致严重阻塞。这种情况常发生在日志处理、外部 API 响应解析、或者数据库导出等场景。

应对方案：

使用流式 JSON 解析库（如 JSONStream、stream-json），让解析逐步进行。
将耗时的 JSON 处理挪到 Worker 线程，主线程仅接收最终的解析结果。
如果 JSON 来自 HTTP 请求，考虑使用 express.json({ limit: '1mb' }) 限制请求体大小，避免被恶意大 payload 攻击。

5. 同步版本的加密、压缩和哈希操作

crypto 模块提供了同步方法（如 crypto.pbkdf2Sync、crypto.randomFillSync），它们会持续占用 CPU 直到操作完成。高并发下，多个请求哪怕是调用一个简单的 bcrypt.hashSync，也会迅速让事件循环屈服。

正确选择：

一律使用异步版本：crypto.pbkdf2、bcrypt.hash。
对于需要大量加解密或签名的场景，也可以将耗时的密钥派生操作单独部署为 Worker 服务，或者通过 worker_threads 并行处理。

6. 在循环中进行同步的数据库或 HTTP 调用

如果代码在遍历数组时，使用同步的 HTTP 客户端或数据库驱动程序发起请求，每次调用都会阻塞事件循环，导致后续请求完全停顿。尽管这种写法看起来像“懒人”的实现，但在 Node.js 中是致命的反模式。

// 错误：同步网络调用，每个请求堵塞事件循环
for (const url of urls) {
  const data = requestSync(url);  // 假设这是同步HTTP方法
  results.push(data);
}

正确做法永远是使用异步调用，并通过 Promise.all 或 async/await 在循环中收集结果，这样可以让这些 I/O 操作并发执行，而不是排队阻塞。

7. 频繁且大量的同步 console.log

虽然 console.log 本身通常是异步的（内部使用 process.stdout.write），但在输出大量数据（比如将整个对象的 JSON 输出到终端）时，底层的管道可能因为缓冲区满而变成同步阻塞，尤其是在生产环境中将日志输出到文件时。因此应避免在请求处理中使用 console.log 打印海量对象，改用专业的日志框架（如 pino）并通过 stream 异步写入。

如何发现事件循环被阻塞？

事件循环的延迟（从 I/O 事件产生到回调开始执行的时间差）是衡量服务健康度的关键指标。我们可以通过以下方式检测：

使用 blocked 或 blocked-at 等 npm 包：它们会定期测量主线程被占用的时间，并在超过阈值时打印警告。
内置 perf_hooks 模块：可以借助 performance.now() 和 setTimeout 来测量回调的实际触发时间与期望时间的偏差。
监控平台：如 PM2、Prometheus + Grafana 等可以对事件循环延迟进行采集和告警。

总结：牢记主线程的职责

事件循环是 Node.js 服务的命脉，任何长时间占用主线程的操作都是“毒药”。开发过程中应时刻保持一个习惯：

I/O 操作必须异步化，大量计算必须拆分或迁移到 Worker。
善用分割思想：大数据拆小批、大文件走流、大计算分片。
永远不要假设一个同步操作很快：哪怕现在数据量小，未来也可能成为瓶颈；从一开始就选择异步或可扩展的模式。

当你掌握了这些避免阻塞的技巧后，Node.js 的高并发优势才能真正体现出来。下一节，我们将进一步讨论如何将 CPU 密集任务科学地拆分与异步化，以及在集群和线程池之间如何做出正确的选择。