Node.js 子进程管理：child_process 模块的正确打开方式

上周五下午，我们的构建服务突然挂了。运维同事扔过来一张监控截图：服务器内存从 2G 飙到 14G，随后 OOM 被系统直接 kill 掉。排查了一个多小时，最后定位到原因------有人在 Node.js 里用 exec 跑了一个日志分析脚本，脚本输出有 800MB，全部缓存在内存里，直接把进程撑爆了。

一行 exec('cat /var/log/app.log') 引发的血案。

这事让我重新审视了 child_process 这个模块。跑脚本、调 CLI 工具、构建流程里拉起子进程------这些操作大家天天在做，但真正理解每个方法的行为边界、知道什么场景该选哪个方法的人，并没有想象中那么多。

四个方法，四种性格

child_process 模块提供了四个创建子进程的核心方法：exec、execFile、spawn、fork。光看 API 签名很难记住它们的区别，不如从适用场景来理解------每个方法擅长干什么活儿。

exec：图省事的一次性命令

exec 的设计思路很直白：你给一条 shell 命令，它跑完把结果一次性返回。

js 复制代码

const { exec } = require('child_process')

exec('ls -la /tmp', (err, stdout, stderr) => {
  if (err) {
    console.error('命令执行失败:', err.message)
    return
  }
  console.log(stdout) // 完整的命令输出，类型是 string 或 Buffer
})

简单粗暴，问题也在这------exec 会把子进程的 stdout 和 stderr 全部缓存在内存里 ，等进程退出后才一次性交给回调。默认的 maxBuffer 是 1MB（Node 12+ 之后是 1024 * 1024 字节），超过直接报错。

开头那个事故的根源就在这里。那位同事把 maxBuffer 改成了 Infinity，想着"这下总不会报错了吧"。报错是不报了，但 800MB 输出全吃进内存，进程直接被操作系统干掉。

exec 还有一个容易被忽略的特性：它会启动一个 shell （Linux 上默认 /bin/sh，Windows 上是 cmd.exe）。管道、重定向、通配符这些 shell 语法都能用，但也意味着存在命令注入风险 。如果拼接了用户输入，比如 exec('grep "' + userInput + '" /var/log/app.log')，一旦 userInput 包含 "; rm -rf /"，后果不堪设想。碰到需要处理用户输入的场景，更安全的做法是换用 execFile。

execFile：不经过 shell 的直接调用

execFile 和 exec 的接口很像，关键区别是不启动 shell，直接执行指定的可执行文件，参数以数组形式传入。

js 复制代码

const { execFile } = require('child_process')

execFile('grep', ['-r', 'TODO', './src'], (err, stdout, stderr) => {
  if (err) {
    // grep 没找到匹配时 exit code 是 1，也会触发 err
    console.error('exit code:', err.code)
    return
  }
  console.log(stdout)
})

少了 shell 解析这一层，execFile 性能稍好，安全性也高很多------参数不会被 shell 二次解释，命令注入无从下手。不过和 exec 一样，它也是缓存全部输出后一次性返回的，大数据量场景同样不适用。

我自己的选择标准：输出在几百 KB 以内，用 execFile；非要用管道、重定向这些 shell 特性，才考虑 exec。

spawn：流式处理的主力

spawn 是 child_process 里最底层也最灵活的方法。它返回一个 ChildProcess 对象，子进程的 stdout 和 stderr 是可读流（Readable Stream），数据到达一批就能处理一批。

js 复制代码

const { spawn } = require('child_process')

const child = spawn('cat', ['/var/log/app.log'])
let lineCount = 0

child.stdout.on('data', (chunk) => {
  // chunk 是 Buffer，数据分批到达，不会一次性吃满内存
  lineCount += chunk.toString().split('\n').length - 1
})

child.on('close', (code) => {
  console.log(`进程退出，exit code: ${code}，共 ${lineCount} 行`)
})

如果开头那个事故用 spawn 来写，800MB 的日志会被切成一个个 chunk 流式处理，内存占用可能只有几十 MB。这就是两者的本质区别------缓存模型不同 。把 exec 想成"先把水全接到桶里再一次性倒给你"，spawn 则是"水龙头直接接根管子到你手上，来多少处理多少"。

spawn 同样支持启动 shell------传个 { shell: true } 就行，这时候可以写管道命令。但一般不推荐，能用参数数组就用参数数组，安全又清晰。

fork：专为 Node.js 脚本设计的 IPC 通道

fork 是 spawn 的特化版本，专门用来跑另一个 Node.js 脚本，并且自动建立父子进程间的 IPC 通信通道。

js 复制代码

// parent.js
const { fork } = require('child_process')
const child = fork('./worker.js')

child.send({ type: 'START', payload: { taskId: 42 } })
child.on('message', (msg) => {
  console.log('子进程返回:', msg) // { type: 'RESULT', data: 1764 }
})

// worker.js
process.on('message', (msg) => {
  if (msg.type === 'START') {
    const result = msg.payload.taskId * msg.payload.taskId
    process.send({ type: 'RESULT', data: result })
  }
})

有一点需要明确：fork 创建的子进程是一个独立的 V8 实例 ，有自己的内存空间和事件循环。它不是线程，是进程，没法共享变量，所有通信都走 send/message 这对消息机制。

这个设计本质上是Actor 模型 的简化版------每个进程是独立的 actor，通过消息传递协作，不共享状态。好处是天然没有竞态条件和锁的问题，代价是通信有序列化/反序列化的开销。如果你的场景是 CPU 密集型计算（比如图片处理、数据聚合），又想利用多核能力，fork 多个 worker 是一个很实用的方案。

错误处理：三种来源，分别应对

子进程的错误有多种来源，处理方式各不相同。搞清楚这三类错误的区别，能省掉大量排查时间。

进程启动失败

命令不存在、权限不够、路径错误------这些在启动阶段就会失败，触发 error 事件。

js 复制代码

const child = spawn('这个命令不存在吧')
child.on('error', (err) => {
  // err.code === 'ENOENT' → 命令不存在
  // err.code === 'EACCES' → 没有执行权限
  console.error('启动失败:', err.message)
})

一个常见的疏忽：只监听了 close 或 exit，漏掉了 error。命令压根启动不了的时候，close 和 exit 在某些 Node 版本和平台上可能不触发，而未处理的 error 事件会直接抛异常，主进程跟着崩溃。

进程被信号杀死

子进程被 SIGTERM、SIGKILL 或其他信号终止时，close 事件的 code 参数是 null，signal 参数是信号名。

一条实战中学到的教训：SIGTERM 只是"请你退出"，子进程可以捕获这个信号做清理，也可以无视 。如果子进程不响应 SIGTERM，需要等一段时间后补发 SIGKILL（无条件强杀，不可被捕获）。

js 复制代码

function killGracefully(child, timeout = 5000) {
  return new Promise((resolve) => {
    child.on('close', resolve)
    child.kill('SIGTERM')
    setTimeout(() => {
      if (!child.killed) child.kill('SIGKILL')
    }, timeout)
  })
}

生产级的错误处理

把三种情况组合起来，一个健壮的子进程调用封装大概长这样：

js 复制代码

function runCommand(cmd, args, options = {}) {
  return new Promise((resolve, reject) => {
    const child = spawn(cmd, args, options)
    const chunks = []

    if (child.stdout) child.stdout.on('data', (chunk) => chunks.push(chunk))

    child.on('error', (err) => reject(new Error(`启动失败: ${err.message}`)))

    child.on('close', (code, signal) => {
      const output = Buffer.concat(chunks).toString()
      if (signal) reject(new Error(`被信号 ${signal} 杀死`))
      else if (code !== 0) reject(new Error(`退出码 ${code}\n${output}`))
      else resolve(output)
    })
  })
}

实战场景：构建系统中的子进程编排

聊点真实项目里的事。我们内部有一个构建平台，需要并行跑多个构建任务（ESLint 检查、TypeScript 编译、单元测试），每个任务是一个独立子进程。这个场景里有几个值得展开的设计决策。

并发控制

最粗暴的方式是 Promise.all 一股脑全启动。20 个任务同时跑的话，CPU 和内存都可能扛不住。我们做了一个简单的并发池------用 Set 跟踪正在执行的 Promise，达到上限就用 Promise.race 等一个空位出来，本质上是一个信号量：

js 复制代码

async function runWithConcurrency(tasks, maxConcurrent = 4) {
  const results = []
  const executing = new Set()

  for (const task of tasks) {
    const p = task().then(result => { executing.delete(p); return result })
    executing.add(p)
    results.push(p)
    if (executing.size >= maxConcurrent) await Promise.race(executing)
  }
  return Promise.all(results)
}

// 最多 3 个任务并行
await runWithConcurrency([
  () => runCommand('npx', ['eslint', 'src/']),
  () => runCommand('npx', ['tsc', '--noEmit']),
  () => runCommand('npx', ['vitest', 'run']),
], 3)

上线前我们对比过：不加并发控制时 8 个构建任务同时跑，峰值内存 3.2GB，偶尔触发 OOM；加了并发池限制到 4 个之后，峰值内存稳定在 1.8GB，构建总耗时只多了 15% 左右（因为部分任务排队等待），稳定性大幅提升。

超时机制

构建任务不能无限跑下去。

js 复制代码

function runWithTimeout(cmd, args, timeoutMs = 60000) {
  return new Promise((resolve, reject) => {
    const child = spawn(cmd, args)
    let timedOut = false

    const timer = setTimeout(() => {
      timedOut = true
      child.kill('SIGTERM')
      setTimeout(() => { if (!child.killed) child.kill('SIGKILL') }, 3000)
    }, timeoutMs)

    child.on('close', (code) => {
      clearTimeout(timer)
      if (timedOut) reject(new Error(`执行超时 (${timeoutMs}ms)`))
      else if (code !== 0) reject(new Error(`退出码: ${code}`))
      else resolve()
    })
    child.on('error', reject)
    if (child.stdout) child.stdout.resume()
    if (child.stderr) child.stderr.resume()
  })
}

这个超时机制有一次真救了命：TypeScript 编译因为循环依赖导致 tsc 跑了 15 分钟还不出来，要不是 60 秒超时兜底，整个构建流水线都会被堵死。没有超时保护的子进程调用，迟早出事。

输出流合并与日志隔离

多个子进程并行跑的时候，输出混在一起根本没法看。我们给每个子进程的输出加了前缀标识，实现方式是对 stdout 流做逐行解析和拼接：

js 复制代码

function prefixStream(stream, prefix) {
  let buffer = ''
  stream.on('data', (chunk) => {
    buffer += chunk.toString()
    const lines = buffer.split('\n')
    buffer = lines.pop() // 最后一个可能不完整，留到下次
    lines.forEach(line => console.log(`[${prefix}] ${line}`))
  })
  stream.on('end', () => { if (buffer) console.log(`[${prefix}] ${buffer}`) })
}

加了前缀之后输出变成这样，哪个任务报了什么问题一目了然：

csharp 复制代码

[ESLint] src/utils.ts:42 - warning: 'foo' is defined but never used
[TSC]    src/types.ts:15 - error TS2345: Argument of type 'string'...
[ESLint]  3 problems (0 errors, 3 warnings)
[TSC]    Found 1 error in src/types.ts:15

从踩坑到原则：子进程管理的五条经验

写了这么多具体的坑和方案，最后提炼几条我在实际项目中反复验证过的原则。

永远不信任子进程会正常退出。 超时机制必须有，进程清理逻辑必须有，error 事件监听必须有。子进程是一个独立的运行时，可能因为任何原因卡死、崩溃、或不响应信号。在我们的构建平台上线初期，没加超时保护那段时间，平均每周都有一两次构建任务卡住不动的情况，加了 60 秒超时后基本消失了。

大数据走流，小数据走缓存。 能确定子进程输出不超过几百 KB，用 exec/execFile 图个方便没问题。超过这个量级，必须用 spawn 做流式处理。不确定的时候，默认选 spawn。回头看开头的事故，如果当时用 spawn 处理那个 800MB 的日志文件，内存占用大概只有 30-50MB，根本不会触发 OOM。

**安全性不是可选项。

跨平台要从第一天考虑。 如果你的工具有任何可能跑在 Windows 上，从一开始就用 cross-spawn 替代原生 spawn，从一开始就不要依赖 POSIX 特性。事后补跨平台支持的成本远比你想的高------我们有一个内部 CLI 工具，最初只考虑了 macOS 和 Linux，半年后要支持 Windows 时，光是改子进程相关的代码就花了两周。

**子进程是最后的手段。

场景	改造前	改造后
800MB 日志分析	exec，内存飙到 14GB 触发 OOM	spawn 流式处理，峰值内存 50MB
8 任务并行构建	无并发控制，峰值内存 3.2GB	并发池限 4，峰值内存 1.8GB
tsc 编译卡死	无超时，阻塞流水线 15 分钟	60s 超时，自动终止并报错
多进程日志混乱	输出交错无法定位问题	前缀标识，按任务隔离日志

这些原则不是从文档里抄来的，是被线上事故教出来的。child_process 是 Node.js 里最强大的模块之一，也是最容易出问题的模块之一。用好它需要对操作系统层面的进程管理有基本的认知------进程间通信、信号机制、文件描述符、管道缓冲区------这些看起来很"底层"的概念，在你排查子进程问题的时候一个都绕不开。

管好子进程和管好团队有相似之处：得明确分工（stdio 配置），得有沟通渠道（IPC），得有超时兜底（timeout），得有退出机制（信号处理），还得在出事的时候能查到是谁的锅（日志隔离）。想明白这些，child_process 就不再是一个让人提心吊胆的黑盒了。