选择 Node.js 进程、线程和分段计算方案

Node.js 的事件循环很适合处理大量等待 I/O 的请求，但 JavaScript 一旦长时间占用执行线程，同一事件循环上的其他请求就只能排队。选择并发方案时，应先回答两个不同的问题：要把哪一类工作移走，以及怎样让单个任务不独占有限的执行资源。

本文合并完整整理 Node.js 官方《Comparing Node.js concurrency models》和《Don’t Block the Event Loop (or the Worker Pool)》。前者比较子进程、工作线程和 cluster，后者解释事件循环与 libuv 线程池的公平性。核对日期为 2026-10-05；第二篇含 Node.js v9、v10 之前的历史说明，本文保留背景并指出适用边界。所有示例只经过静态审核，未执行、未压测。

一、先分清四种执行资源

通常所说的“Node.js 在单线程运行 JavaScript”，指的是一个事件循环上的 JavaScript 回调。它不意味着进程里只有一个操作系统线程，也不意味着异步工作都交给同一类线程。网络等待可以通过操作系统的非阻塞机制处理；部分文件操作和计算型 API 使用 libuv 工作线程池；worker_threads 则允许应用建立具有独立 JavaScript 执行环境的线程。

cluster 建立在 child_process 之上，主要解决网络服务的多进程扩展；worker_threads 主要用于把 CPU 密集的 JS 工作移出主线程，避免为每项工作承担完整新进程成本。libuv 线程池与应用创建的 Worker 不是同一个概念。

二、child_process：运行其他程序或需要完整进程隔离

如果工作已经由外部二进制工具、Shell 命令、其他语言脚本完成，或者需要一个独立的 Node.js 进程，通过标准流或 IPC 驱动它，优先考虑 node:child_process。

exec() 和 execFile() 会受 maxBuffer 限制。当前参考 API 的默认值为 1 MiB；输出超过限制可能导致子进程终止和输出截断。持续输出、视频转码日志或无法预估体积的结果更适合流式读取。

用 spawn 流式读取 ffmpeg 输出

下面保留原文的转码场景，补上启动失败处理。它依赖已安装的 ffmpeg 和当前目录中的输入文件，会创建输出文件，不是可直接放进任意服务器请求处理器的完整生产方案。

const { spawn } = require('node:child_process');

const child = spawn('ffmpeg', ['-i', 'input.mp4', 'output.mp3'], {
  shell: false,
  windowsHide: true,
});

child.stdout.on('data', data => console.log('stdout:', data.toString()));
child.stderr.on('data', data => console.error('stderr:', data.toString()));
child.on('error', error => console.error('启动子进程失败:', error));
child.on('exit', (code, signal) => {
  console.log('进程退出:', { code, signal });
});
child.on('close', (code, signal) => {
  console.log('标准流已关闭:', { code, signal });
});

原文同时展示 CommonJS 和 ESM 两种写法。使用 ESM 时，把第一行改为 import { spawn } from 'node:child_process';，其余逻辑相同。exit 表示进程退出，close 在相关标准流关闭后发生；清理逻辑应避免在多个事件处理器中重复执行。

传入参数数组可以避免把输入拼成 Shell 命令，但这只解决 Shell 解释这一层的问题。可执行文件自身仍会解释选项、路径和 URL；必须限制程序路径、可用参数和文件访问范围，防止参数注入、路径越界或调用不应使用的协议。大流量输出还应采用适当的流处理和背压，避免日志系统成为新的瓶颈。

用 fork 进行父子进程通信

父进程 parent.js：

const { fork } = require('node:child_process');
const child = fork('./child.js', [], { serialization: 'json' });

child.on('error', error => console.error('子进程错误:', error));
child.on('message', result => console.log('子进程结果:', result));
child.on('exit', (code, signal) => console.log('退出:', code, signal));
child.send({ task: 'start', data: 42 }, error => {
  if (error) console.error('发送失败:', error);
});

子进程 child.js：

process.on('message', message => {
  if (!message || message.task !== 'start') return;
  console.log('收到任务:', message);
  if (process.send) process.send('done');
});

这里显式使用默认的 JSON 序列化，以免误读原文。并发模型指南把 fork() 的通道称为基于结构化克隆，但当前 API 明确写明 serialization 默认是 'json'；只有选择 'advanced' 才启用基于 V8 序列化和 HTML 结构化克隆机制的模式。高级模式可以处理更多内建类型，但也不是 JSON 的无条件超集，性能和自定义属性保留规则需要单独核对。

示例中的 IPC 监听会持续保留子进程，实际应用还要定义完成、取消、断开和超时协议，并控制消息大小与发送队列。独立进程提供的是地址空间隔离，不是针对不可信代码的自动安全沙箱。

三、worker_threads：把 CPU 密集的 JavaScript 移出主线程

密码派生、图像或视频变换、大型内存数据解析等工作会消耗大量 CPU。把这些工作放到另一个 Worker 的 JavaScript 线程，可以让主线程继续处理连接和回调。与子进程相比，Worker 通常启动成本较低，但仍有创建执行环境、分配内存和消息传输的实际成本；这些不是无需测量即可保证的速度差。

保留盐值的密码派生演示

原文使用同步 scryptSync() 演示 CPU 工作移入 Worker，但只返回哈希、不返回盐值。下面把盐与算法参数一起返回，说明数据闭环；这仍不是完整的密码存储、验证、升级或账号系统实现。演示输入是固定字符串，实际程序不应把明文密码或派生结果写入日志。

main.js：

const { Worker } = require('node:worker_threads');
const worker = new Worker('./hash-worker.js', {
  workerData: 'demonstration-only',
});

worker.on('message', record => {
  // 交给受保护的凭据存储层；不要记录明文密码或派生结果。
  console.log('派生完成，算法:', record.algorithm);
});
worker.on('error', error => console.error('Worker失败:', error));
worker.on('exit', code => {
  if (code !== 0) console.error('Worker异常退出，代码:', code);
});

hash-worker.js：

const { parentPort, workerData } = require('node:worker_threads');
const { scryptSync, randomBytes } = require('node:crypto');

if (typeof workerData !== 'string') throw new TypeError('需要字符串输入');
const salt = randomBytes(16);
const params = { N: 16384, r: 8, p: 1, maxmem: 32 * 1024 * 1024 };
const keyLength = 64;
const hash = scryptSync(workerData, salt, keyLength, params);
parentPort.postMessage({
  algorithm: 'scrypt',
  salt: salt.toString('hex'),
  hash: hash.toString('hex'),
  keyLength,
  params,
});

同步派生现在占用的是该 Worker，不再占用主事件循环；它仍会消耗 CPU 和内存。实际密码参数要按适用安全要求及服务容量选定，队列、密码输入长度、并发和失败处理也需要限制。Node.js 已有异步密码学 API，会使用 libuv 线程池；不要机械地认为所有哈希场景都必须另建 Worker。

共享内存与线程池

普通对象通过 postMessage() 传递时，不会变成两个线程随意修改的同一个 JS 对象。需要大量共享二进制数据时，可使用 SharedArrayBuffer 配合 Atomics 协调访问，减少复制和序列化开销；代价是应用必须负责同步、内存可见性和竞态，不能把“共享”误当作天然安全。

不要为了普通数据库查询或网络请求随手创建 Worker：这些任务的等待通常已经由 Node.js 的异步 I/O 机制处理。频繁的小计算也未必值得每次启动一个线程。原文建议考虑长期存活的线程池，并给出 workerpool 作为阅读入口；采用第三方池之前仍需核对维护状态、接口成本和资源控制。池必须有最大并发、队列长度和过载策略。

四、cluster：让多个进程共同提供网络服务

cluster 会派生多个完整的 Node.js 进程，让它们监听同一个服务端口。每个进程都有自己的事件循环和内存，因此可以把网络请求处理分布到多个 CPU 核。一个进程的单个 JavaScript 事件循环仍然受前面讨论的约束。

原文按照 availableParallelism() 创建工作进程，并在非主动退出后立即重启。下面保留示例结构，补上有上限的退避，避免持续崩溃时形成无限高速重启循环。代码只是进程管理机制演示，生产环境仍需要成熟的健康检查、优雅停机、日志和运维管理。

const cluster = require('node:cluster');
const http = require('node:http');
const { availableParallelism } = require('node:os');

if (cluster.isPrimary) {
  let failures = 0;
  const maxRestarts = 5;
  for (let i = 0; i < availableParallelism(); i++) cluster.fork();

  cluster.on('exit', (worker, code, signal) => {
    if (worker.exitedAfterDisconnect) return;
    failures++;
    console.error('工作进程异常退出:', worker.process.pid, code, signal);
    if (failures > maxRestarts) {
      console.error('已达到示例重启预算，交由运维处理');
      return;
    }
    const delay = Math.min(1000 * 2 ** (failures - 1), 30000);
    setTimeout(() => cluster.fork(), delay);
  });
} else {
  const server = http.createServer((req, res) => {
    res.writeHead(200);
    res.end('handled by worker ' + process.pid);
  });
  server.on('error', error => {
    console.error('HTTP服务错误:', error);
    process.exitCode = 1;
  });
  server.listen(3000);
}

cluster.isPrimary 在创建工作进程的主进程中为真；派生进程可用 cluster.isWorker 判断身份。旧代码里的 isMaster 是已弃用的别名。worker.exitedAfterDisconnect 用于区分 worker.disconnect() 或 cluster.disconnect() 导致的主动退出；否则优雅停机可能被错误识别成崩溃，刚关闭的进程又不断重建。

默认连接分发策略也与平台有关。Windows 以外平台默认采用 cluster.SCHED_RR，由主进程按轮转方式分配连接，可通过 cluster.schedulingPolicy 调整。这不是简单地依赖 SO_REUSEPORT 的默认实现。应按实际平台检查配置，不能把某个平台上的行为推广到所有系统。

工作进程不共享内存。会话、缓存和限流计数如果只存于某个进程，就不会自动被其他进程看到；需要共享状态时，可以使用 Redis 等外部存储，并设计一致性与失效规则。未处理的工作进程崩溃会悄悄减少服务容量；只会无限重启的处理同样不可靠。原文指出，生产环境通常使用 PM2、systemd 或容器编排器管理进程生命周期。

五、选择方案，以及组合时的资源总账

• 运行外部程序或其他语言脚本：考虑 spawn() 或 execFile()。
• 需要独立 Node.js 进程和结构化消息协议：考虑 fork()，明确其序列化模式。
• CPU 密集 JavaScript 拖慢主事件循环：考虑 worker_threads 或长期计算池。
• 网络服务要利用多个 CPU 核：考虑 cluster，或由进程管理器、编排系统提供等价部署。

这些选项可以组合。例如图片上传服务可用多个服务进程接收请求，再把图像计算交给 Worker 或外部工具。组合时要统计整个主机的进程数、线程数、并发任务和排队内存；不能只给每一层设一个“看起来不大”的上限，却让它们相乘后耗尽资源。

六、为什么事件循环和线程池都不能长时间阻塞

第二篇指南主要面向服务器，也适用于比短命令行脚本更复杂的 Node.js 应用；涉及操作系统细节时以 Linux 为背景。它的核心并不是“Node.js 永远比多线程服务器快”，而是：用较少线程服务大量客户端，可以节省线程内存和上下文切换，但前提是每个客户端在某一时刻占用的工作量足够小。

一个线程长时间执行某个回调或任务时，就无法处理其他客户端的工作。后果有两层：吞吐量和响应延迟变差；若攻击者可以提交特定昂贵输入，还可能制造拒绝服务。这个原则同时适用于事件循环上的 JavaScript 和有限线程池里的原生任务。

事件循环到底执行什么

应用先完成初始化，加载模块、注册事件回调，然后进入事件循环。收到请求时调用相应回调；回调本身同步执行，可以发起异步请求，等待完成后再由事件循环执行后续回调。await 或 Promise.then() 中恢复执行的 JavaScript 同样会占用该事件循环，不能因为外层函数带有 async 就忽略其计算成本。

事件循环还协调网络 I/O 等非阻塞操作。把它画成“一个待处理事件队列”有助于理解，但底层并不是只有一个简单队列：它依赖操作系统监视文件描述符或相应 I/O 对象，例如 Linux 的 epoll、macOS 的 kqueue、Solaris 的 event ports，以及 Windows 的 IOCP。当相应资源就绪时，再形成事件并调用关联回调。

libuv 工作线程池执行什么

libuv 提供任务提交机制，Node.js 用它处理操作系统没有合适非阻塞形式的 I/O，以及部分昂贵计算。官方指南列出这些典型接口：

• DNS：dns.lookup()、dns.lookupService()。
• 文件系统：多种异步文件系统操作使用线程池；文件监视和显式同步接口应另行区分。应按实际 Node.js 版本查看所用 API，不能仅靠模块名判断。
• 密码学：异步 crypto.pbkdf2()、crypto.scrypt()、crypto.randomBytes()、crypto.randomFill()、crypto.generateKeyPair()。
• 压缩：zlib 的异步操作；显式同步版本会在调用线程上执行。
• 原生扩展：C++/Node-API 扩展也可以提交工作任务。

调用这些接口时，主事件循环仍要做进入原生绑定、准备参数和提交任务的工作，只是相对昂贵的主要任务通常移到了线程池。线程池维护真实的任务队列；一个 Worker 取出任务、执行完成，再通知事件循环处理完成事件。异步回调的执行位置与后台任务的位置不同。

公平调度是应用设计的一部分

在某些“一客户端一线程”的服务器模型中，操作系统可抢占一个忙碌线程，让另一个客户端运行。Node.js 让许多客户端共享少量线程，因此某个客户端占用一个回调过久，其他等待该线程的客户端就没有机会。这意味着应用要主动设计公平性：限制单次输入和单段工作，必要时让出事件循环，或把长任务分流到适当资源。

原文用 Apache 作模型对照，目的在于解释调度责任；不能据此把所有 Apache 部署归为同一种线程模型，也不能推出未经负载验证的性能排名。

七、从回调的复杂度检查阻塞风险

一个回调若无论输入多长都只做固定数量的工作，通常容易界定最长占用时间。如果工作次数随输入变化，就必须同时分析复杂度和最大输入。原文用三个 Express 风格片段展示区别，下面保留它们作为静态反例；这些片段假定已有 app，不是完整服务器，不应部署到可接收任意输入的公开路由。

// O(1)：示意固定工作量。
app.get('/constant-time', (req, res) => {
  res.sendStatus(200);
});

// O(n)：输入越大，事件循环连续工作越久。反例，缺少输入上限。
app.get('/countToN', (req, res) => {
  const n = req.query.n;
  for (let i = 0; i < n; i++) console.log('Iter', i);
  res.sendStatus(200);
});

// O(n²)：嵌套循环会更快放大成本。反例，不能直接用于公网请求。
app.get('/countToN2', (req, res) => {
  const n = req.query.n;
  for (let i = 0; i < n; i++) {
    for (let j = 0; j < n; j++) console.log('Iter', i, j);
  }
  res.sendStatus(200);
});

两个循环示例还有类型强制转换、日志体积和未设置上限的问题。实际接口应先把输入解析为期望类型，检查有限值、整数范围和业务上限，再选择分段或移交执行。上限需要从可接受的最坏延迟与资源预算得出，不应把示例中任意数字当成通用安全阈值。

V8 对许多常见操作执行很快，但“通常很快”不能替代最坏情况分析。尤其要留意正则表达式和 JSON 操作。对于复杂任务，限制输入尺寸并拒绝超限请求，是让最坏成本可计算的基本步骤。

八、正则表达式的 REDOS 风险

正则匹配常被想象为扫描一次字符串，即 O(n)。但某些模式在回溯引擎和特定不匹配输入下，可能尝试指数数量的路径。如果输入每增加少量字符就让尝试次数急剧上升，一次匹配就能长时间占用事件循环。

原文给出的审核启发包括：避免嵌套量词，如 (a+)*；警惕分支互相重叠，如 (a|a)*；慎用回溯引用，如 (a.*) \1。不同引擎的优化和支持范围不同，这些是风险线索，不能仅凭某个模式形状就断言所有引擎一定以相同方式退化。简单子串查找可以用 indexOf()，不必引入复杂正则。

危险模式经常在“成功匹配”时表现正常，真正的问题出现在不匹配时：引擎需要尝试许多路径后才能确信失败。因此只测几个合法输入不足以排除风险。

路径校验反例

// 仅用于静态分析：原文指出的易受REDOS影响模式。
app.get('/redos-me', (req, res) => {
  const filePath = req.query.filePath;
  if (filePath.match(/(\/.+)+$/)) {
    console.log('valid path');
  } else {
    console.log('invalid path');
  }
  res.sendStatus(200);
});

该表达式试图识别类似 /a/b/c 的斜杠分隔路径，却含有嵌套量词。原文用大量斜杠末尾接换行的输入解释回溯风险；这里保留原理，不运行或生成攻击请求。这个模式也不是完整的文件路径权限验证。生产逻辑应采用明确的解析规则、输入长度限制、规范化路径和允许访问根目录的检查，不能把“看起来像路径”当成获得文件访问权限。

原文列出 safe-regex、rxxr2 等辅助分析资源，并强调工具无法捕获全部问题。也可评估基于 Google RE2 的 node-re2；它与 V8 正则并非完全兼容，一些复杂特性不受支持，替换后必须检查语义变化。采用正则库或 npm 包也不免除对实现、输入上限和最坏成本的审核。

九、不要在服务热路径使用昂贵的同步 API

密码学、压缩、文件系统和子进程模块都有方便脚本使用的同步接口。在事件循环中调用时，计算或等待期间会一直占用调用线程。官方旧指南列举：

• 同步形式的 crypto.randomBytes()、crypto.randomFillSync()、crypto.pbkdf2Sync()，以及输入很大的加密、解密操作。
• zlib.inflateSync()、zlib.deflateSync()。
• 同步文件系统 API；尤其是访问 NFS 等外部或分布式存储时，延迟可能大幅波动。
• child_process.spawnSync()、execSync()、execFileSync()。

原文注明这个清单在 Node.js v9 时“相对完整”，它不是当前所有 API 的穷尽清单。使用新的同步接口时仍要遵守同样原则。短命令行工具、启动初始化或专用 Worker 与高并发请求热路径的约束不同，应按照运行位置和最长占用时间判断，而不是机械禁止所有同步代码。

十、JSON 也能长时间阻塞

JSON.parse() 和 JSON.stringify() 通常随输入大小线性增长，但足够大的字符串或对象仍会造成明显停顿，并额外消耗内存。接收客户端 JSON 时，不能只限制网络包数量，还要控制解压后的正文尺寸、对象深度和后续序列化的输出量。

原文构造层层复用子对象的结构，再进行序列化、子串查找和反序列化。下面保留该演示供静态阅读。它会产生很大的内存负担，不应直接在共享或生产环境执行：

// 大对象阻塞反例，仅供阅读；未运行。
let obj = { a: 1 };
const iterations = 20;
for (let i = 0; i < iterations; i++) {
  obj = { obj1: obj, obj2: obj };
}

let start = process.hrtime();
const jsonString = JSON.stringify(obj);
let duration = process.hrtime(start);
console.log('JSON.stringify耗时', duration);

start = process.hrtime();
const index = jsonString.indexOf('nomatch');
duration = process.hrtime(start);
console.log('String.indexOf耗时', duration);

start = process.hrtime();
const parsed = JSON.parse(jsonString);
duration = process.hrtime(start);
console.log('JSON.parse耗时', duration);

原文报告的样例 JSON 大小约为 50 MB，并给出约 0.7 秒序列化、0.03 秒查找、1.3 秒解析的结果。这些是原文案例数据，未在本次环境复现，不能作为当前硬件、V8 版本或业务输入的性能承诺。

原文提供 JSONStream 和 Big-Friendly JSON 等流式或异步接口阅读入口。采用这类方案时，要检查它是否真的以有限大小处理每一段，以及是否正确传递背压；仅仅返回 Promise 并不意味着解析过程已经离开事件循环。

十一、分段计算：让出执行机会，但不会增加 CPU 核

如果任务可以拆成短小步骤，可以保留状态并通过 setImmediate() 安排下一段，使其他待处理事件有机会运行。JavaScript 闭包适合保存进行中的状态。原文以求 1 到 n 的平均值说明 O(n) 连续循环与每段 O(1) 的区别。

原文同步例却累加 0 到 n−1，而异步例累加 1 到 n；下面统一为 1 到 n，并补上正整数与规模校验。上限 100000 只是本演示的选择，不是性能安全保证。实际求这个特定数列的平均值可直接使用数学公式；循环的目的只是展示调度方式。

function validateN(n) {
  if (!Number.isSafeInteger(n) || n < 1 || n > 100000) {
    throw new RangeError('本演示要求1到100000之间的安全整数');
  }
}

// 不分段：整段循环连续占用当前线程。
function syncAvg(n) {
  validateN(n);
  let sum = 0;
  for (let i = 1; i <= n; i++) sum += i;
  return sum / n;
}

// 分段：每次只做一次加法，再让出事件循环。
function asyncAvg(n, avgCB) {
  validateN(n);
  if (typeof avgCB !== 'function') throw new TypeError('需要回调函数');
  let sum = 0;
  let i = 1;
  function step() {
    sum += i;
    if (i === n) {
      avgCB(sum / n);
      return;
    }
    i++;
    setImmediate(step);
  }
  setImmediate(step);
}

asyncAvg(100, average => console.log('1到100的平均值:', average));

原文的异步递归用 help.bind(null, i + 1, cb) 安排下一次调用，与这里保存 i 的闭包表达的是同一分段思路。补上输入校验也避免了原例对 0、负数、非整数等值无法按预期到达结束条件的问题。

每次只做一次加法便于说明 O(1)，但调度开销也很高；实际应用可以处理有限大小的一批，再根据最长占用预算让出执行。把 n 个数拆成两半，每次做 O(n) 工作，即使接口形式上异步，也仍可能造成长时间阻塞。分段改善的是公平性和响应机会，工作仍在同一个事件循环上执行，不会自动获得多核并行。

十二、把复杂计算移交出去：成本和边界

计算复杂到无法通过短段执行满足延迟要求时，可移交给计算线程池或进程池。主事件循环适合协调请求，而不适合独占执行全部昂贵计算。原文旧指南介绍两条路径：通过原生扩展提交到内建线程池，或维护独立计算池；它提到旧版本 NAN、新版本 Node-API，以及历史第三方模块和基于子进程的池。

结合第一篇较新的并发指南，当前纯 JavaScript CPU 工作应同时考虑内建 worker_threads。本文保留旧指南的扩展思路，但不把 node-webworker-threads 等旧入口当作未经重新核验即可采用的当前依赖建议。

不要为每个客户请求无上限地创建子进程或线程。请求进入速度可能超过创建和回收速度，最终形成资源耗尽。工作池需要限制执行中的任务、等待队列、单任务输入与输出，并定义取消、截止时间、重试和过载拒绝。

移交也有通信成本。Worker 不能直接修改主线程的任意普通 JS 对象，通常需要传递数据副本或结果补丁；大对象的序列化、复制、内存峰值，甚至把结果合并回主线程的步骤，都可能重新成为瓶颈。共享缓冲区是特定的显式机制，需要同步设计，并不推翻普通对象隔离这一原则。

CPU 密集和 I/O 密集任务适合不同的资源策略。CPU 任务只有被调度到逻辑核上时才推进；工作线程多于可用 CPU 并行能力不会凭空增加算力，反而可能增加内存与调度成本。I/O 任务等待外部系统时可以被操作系统换出，让别的任务发起请求；数据库、文件系统也可能针对并发请求做合并和调度优化。因此，把所有长 CPU 任务和 I/O 任务混在同一个小池里，可能让两者互相拖累。

可以评估建立独立计算池，隔离计算与 I/O 等待。简单数组遍历可能适合分段；较重计算可能足以抵消移交成本并受益于多核。如果服务的核心几乎全是昂贵计算，还应重新评估语言、运行时或专用计算服务是否更适合，而不是无限增加 Node.js 线程。

十三、线程池同样需要公平：减少任务时长差异

假设线程池有 k 个 Worker，而同时等待服务的客户远多于 k。每个 Worker 通常先完成当前任务，才能取下一个。某个任务特别慢时，它在完成前实际上让可用池容量减少了一个；多个长任务占满池后，短任务即使计算量很小也会等待。

目标不只是“增加线程”，而是减少提交任务的时长差异，让短任务有机会完成。即使把数据库和文件系统当作外部黑盒，也应了解不同 I/O 请求的大致成本，避免提交已知可能无限等待或极端昂贵的工作。

文件读取的历史例子

原文说明，在 Node.js v10 之前，fs.readFile() 的读取任务还没有按后来的方式分段：一次较大的读取可能持续占用某个 Worker，因此大小文件混合会让任务时长差异扩大。这里保留其历史背景，不能把“未分段”当成当前所有版本的 fs.readFile() 行为。

原文还举出目录遍历导致任意文件读取的风险，并用 Linux /dev/random 说明特殊设备可能使读取长时间等待。该设备的行为取决于内核版本、随机源和读取方式，不应把旧文“近乎永远不完成”的表述当成所有当前 Linux 系统的固定事实。稳定的安全结论是：不允许请求者任意指定主机文件或特殊设备；限制路径、数据量和任务时限，而不是依赖某一个设备恰好不阻塞。

随机字节生成的例子

异步 crypto.randomBytes() 把所请求的一批随机字节作为线程池任务。为不同客户生成差别很大的数量，也会造成任务时长差异。若业务真的需要大量随机数据，可以评估分成合理大小的多批，而不是允许单次输入无上限扩大。分段大小仍需结合实际 API 版本、吞吐和延迟测试。

把大任务拆成成本相近的小任务

分段方式是：当前子任务完成后，再提交下一子任务；最后一个完成时通知调用者。文件读取可以显式使用 fs.read() 管理批次，或通过读取流逐步消费。CPU 任务也可以采用同样方式。短任务产生较少子任务，长任务产生较多子任务，但长任务的相邻批次之间，Worker 可以处理其他客户的任务。

衡量收益时应看完整业务任务完成量与延迟，而不是“每秒子任务数”。把一个任务拆成一千个后，子任务计数增长不等于用户得到服务的速度提高。分段也增加任务封装、入队和调度成本，必须在公平性与额外开销之间权衡。

另一种办法：长短任务分池

如果能事先可靠地区分短任务和长任务，例如数组求和与大型排序，可以把它们路由到不同池。每个池的任务时长更接近，短任务不必排在长任务之后，也可以减少手工拆分的复杂度。

但多个池中的线程依然争用同一组 CPU、内存和 I/O 资源。它们不会相互隔绝硬件成本，创建过多池可能让整体表现更差。因此长短任务分池应经过具体分析，而不是看到队列就再增加一个池。无论选择哪种方式，目标都是提高完整任务吞吐并改善尾部延迟。

十四、第三方 npm 包也需要成本审核

使用 npm 包时，除了“是否遵守接口约定”，还应问：“这个接口会在事件循环或某个 Worker 上占用多久？”许多包没有给出运行成本保证。简单字符串操作还容易估算，复杂解析、压缩、模板、加密或文件处理往往需要阅读实现、向维护者确认，或在实际输入分布下测量。

异步接口同样可能存在大段同步工作，也可能提交一个特别长的线程池任务。前面的 asyncAvg 正好说明这一点：是否异步、是否分段、每段多大，以及执行在哪个资源上，是四个需要分别回答的问题。

因此，选择并发模块只是设计的一部分。还要让正常输入与恶意输入都受到可解释的资源限制，让事件循环能够及时返回，让工作线程池有机会服务不同客户。静态分析能识别明显的无限输入、错误序列化和缺失错误处理，但无法替代目标版本、硬件和负载下的延迟与容量验证。

来源、署名与版本说明

原文由 Node.js 文档贡献者维护：Comparing Node.js concurrency models、Don’t Block the Event Loop (or the Worker Pool)。进一步参考 child_process API、worker_threads API、cluster API和事件循环指南。本次 child_process 在线 API 标识为 Node.js v26.10.0；示例的最低版本与实际部署兼容性需另行核对。

Copyright OpenJS Foundation and Node.js contributors. All rights reserved. 中文翻译及编辑标注：未完纪，2026-10-05。正文明确标出对原文的修正：fork 序列化默认值、spawn 的 error 处理、密码盐与参数返回、cluster 有界退避、平均值区间与输入校验、历史 API 和 Linux 特殊设备边界。未运行任何服务器、子进程、Worker、攻击请求或大型对象示例。

MIT License

Copyright Node.js Website WG contributors. All rights reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.