Node.js子进程三剑客：exec、spawn与fork原理与实战
1. 项目概述：为什么“启动子进程”是 Node.js 开发绕不开的硬功夫？
在 Node.js 的世界里，child_process模块不是个可有可无的配角，而是支撑起大量真实业务场景的底层脊梁。你写一个 Web 服务，用exec调用ffmpeg转码视频；你做自动化测试，用spawn启动一个 Python 脚本校验数据；你构建微服务架构，用fork创建带 IPC 通信能力的工作进程；甚至你在 CI/CD 流水线里跑npm run build，背后也是spawn在默默调度 shell。这些都不是“炫技”，而是工程落地时最朴素、最直接的解法——让 Node.js 去干它不擅长的事，把重活、脏活、阻塞活、遗留系统对接活，交给更合适的工具去完成。
我做过三个不同量级的项目：一个日均处理 20 万张图片的电商图床，一个对接银行核心系统的金融风控中间件，还有一个给政府单位做的离线报表生成平台。它们有个共同点：主服务必须轻、快、稳，但又无法避免调用外部命令、遗留二进制程序或 CPU 密集型脚本。这时候，exec、spawn、fork就不是 API 列表里的三个单词，而是你手里的三把扳手——哪把拧哪颗螺丝，得看螺纹规格、扭矩要求和现场空间。很多人卡在第一步：看到文档里exec('ls -l')就以为会了，结果上线后内存暴涨、进程僵死、错误信息全丢、父子进程信号乱飞。这不是 Node.js 不行，是你没摸清这三把扳手的力学特性、握持角度和发力时机。
这篇文章不讲抽象概念，不堆代码片段，只讲我在生产环境里亲手拧过上千次螺丝后总结出的实操逻辑：什么时候该用spawn而不是exec？fork真的比spawn“高级”吗？为什么spawn启动node脚本时加--inspect会失败？stdio配置里的'pipe'、'ignore'、'inherit'到底在管道里流的是什么？detached: true是真·脱离还是假·脱离？这些问题的答案，藏在操作系统进程模型、Node.js 事件循环机制和 V8 进程生命周期的交叉地带。我会用真实调试日志、内存快照对比、strace 系统调用跟踪和线上事故复盘来一层层剥开。如果你正在为子进程卡顿、OOM、信号丢失、输出截断而头疼，或者刚被ENOENT、EPIPE、SIGTERM搞得怀疑人生，那接下来的内容，就是你该抄在笔记本第一页的 checklist。
2. 核心设计思路拆解：exec、spawn、fork本质不是三个 API，而是三种进程协作范式
2.1 从操作系统视角看：Node.js 子进程的本质是fork()+execve()的封装
在 Linux/macOS 上，任何进程创建子进程都绕不开两个系统调用：fork()和execve()。fork()复制当前进程的内存页（COW 机制），得到一个几乎一模一样的副本；execve()则用新程序替换掉这个副本的内存映像，让它开始执行新逻辑。Node.js 的child_process模块，本质上就是对这一对底层操作的 JavaScript 封装。理解这点，是区分exec、spawn、fork的第一把钥匙。
exec：它内部先fork()出子进程，再在子进程中调用execve()执行你传入的完整命令字符串（如'ls -l /home'）。关键在于，它把整个命令字符串交给 shell（通常是/bin/sh）去解析。这意味着你能用管道|、重定向>、分号;、变量$PATH—— 因为 shell 在帮你干活。但代价是：多了一层 shell 进程，启动慢、内存开销大、安全性风险高（命令注入漏洞）。spawn：它跳过 shell 解析，直接调用execve()。你必须把命令和参数拆成数组：spawn('ls', ['-l', '/home'])。没有 shell，就没有管道和重定向语法（除非你手动配置stdio实现），但换来的是极致的启动速度、最小的内存占用和最高的安全性。它适合执行已知路径的二进制程序，尤其是那些需要持续交互、流式处理输出的场景（比如ffmpeg、tail -f、python script.py）。fork：这是spawn的一个特化版本，专为启动另一个 Node.js 进程而生。它内部调用的仍是spawn，但做了三件事：1）自动设置execPath为当前 Node.js 可执行文件路径；2）自动将--require、--inspect等调试参数透传；3）最关键的是，默认启用 IPC（Inter-Process Communication）通道，让你能用process.send()和process.on('message')在父子进程间传递结构化数据（JSON 对象），而不仅仅是字节流。它不是为了“替代”spawn，而是为了在 Node.js 生态内构建进程间协作网络。
提示：
fork启动的子进程，其process.argv[1]是子 JS 文件路径，process.execArgv包含父进程传来的 Node.js 参数（如['--inspect=9229']），process.env继承自父进程。这三点决定了你能否在子进程中正确加载模块、开启调试、读取环境变量。
2.2 选型决策树：三把扳手，何时用哪一把？
选错 API，就像用活动扳手拧精密螺丝——要么打滑，要么崩牙。下面这张决策树，是我根据过去五年线上事故统计提炼出的硬性规则：
| 场景特征 | 推荐 API | 关键原因 | 典型反例 |
|---|---|---|---|
| 执行简单命令，需 shell 功能（管道、变量、通配符）且输出量小（< 1MB） | exec | 语法简洁，stdout直接返回Buffer，适合一次性获取结果 | 用exec('find /var/log -name "*.log" | head -10')处理海量日志，导致内存 OOM |
| 执行外部二进制程序，需实时流式处理输出/输入，或执行时间长、内存敏感 | spawn | 输出以Stream形式暴露，可.pipe()、.on('data')，内存恒定；支持kill()精确控制 | 用exec('tail -f /var/log/app.log')，因exec等待 EOF 而永远不触发回调 |
启动另一个 Node.js 脚本，需父子进程双向通信、共享调试端口、或需process.send()发送复杂对象 | fork | 自动建立 IPC 通道，send()序列化/反序列化 JSON，比spawn的stdin/stdout字节流更安全高效 | 用spawn('node', ['worker.js'])实现任务分发，却要自己解析stdoutJSON 字符串，易出错 |
一个血泪教训：我们曾用exec调用java -jar analyzer.jar分析用户上传的 PDF，单次分析耗时 3~5 秒，输出约 200KB JSON。初期一切正常，但当并发量升到 50+ 时，Node.js 主进程内存从 200MB 暴涨到 1.2GB，GC 频率飙升，响应延迟超 2s。排查发现：exec为每个请求都 fork+shell+execve，shell 进程本身占 10MB 内存，且exec的buffer默认大小是 10MB，即使实际输出只有 200KB，它也会预分配 10MB 空间。换成spawn('java', ['-jar', 'analyzer.jar'])后，内存稳定在 300MB，延迟降至 800ms。exec的便利性，是以内存和启动时间为代价的；当你需要“可控”和“可扩展”，spawn是唯一选择。
2.3fork的隐藏价值：不只是“启动 Node.js”，更是构建进程拓扑的基石
很多开发者把fork当作spawn('node', [...])的语法糖，这是巨大误解。fork的 IPC 通道，是构建健壮进程拓扑的核心基础设施。举个真实案例：我们为某券商开发的实时行情分发服务，主进程（Master）负责接收上游 WebSocket 行情源，子进程（Worker）负责将行情推送给下游数千个客户端连接。如果用spawn，Master 得把行情数据序列化成字符串，通过stdin写入，Worker 再从stdout读取、解析——这引入了额外的序列化开销和粘包风险。而用fork，Master 直接worker.send({ symbol: 'AAPL', price: 182.34, ts: Date.now() })，Worker 收到的就是原生 JavaScript 对象，V8 引擎在 IPC 层做了零拷贝优化（对于小对象）和高效序列化（对于大对象）。更重要的是，IPC 通道天然支持worker.disconnect()和worker.on('disconnect')，Master 能精确感知 Worker 是否优雅退出，从而触发重启或降级策略。
注意：
fork的 IPC 通道是单向命名管道（Unix Domain Socket），它不经过网络栈，延迟极低（微秒级），但有消息大小限制（Linux 默认 64KB）。超过此大小的消息会被截断，且send()会返回false。实践中，我们约定：IPC 只传控制指令和小数据（如任务 ID、状态码），大 payload（如原始行情快照）走 Redis Pub/Sub 或共享内存。这是fork的黄金法则——用对地方，事半功倍；用错地方，寸步难行。
3. 核心细节与实操要点：stdio、detached、signal的魔鬼细节
3.1stdio配置：管道里的水，流向哪里决定生死
stdio选项是spawn和fork的心脏阀门，它控制着子进程的stdin、stdout、stderr三股水流的去向。它的值可以是字符串（'pipe'、'ignore'、'inherit'）或数组（[stdin, stdout, stderr]）。看似简单，却是线上事故最高发区域。
'pipe'（默认）：为对应流创建新的Stream对象。stdout可.on('data')监听，stdin可.write()写入。这是最常用也最灵活的模式，但必须手动.pipe()或.on('data')，否则数据会堆积在缓冲区，最终触发Error: write after end或EPIPE。我见过太多人写了spawn('grep', ['error'])却忘了监听stdout，导致子进程因管道满而阻塞。'ignore'：关闭对应流。stdin设为'ignore'，子进程就无法从父进程读取输入；stdout/stderr设为'ignore'，输出会被丢弃。这常用于后台守护进程，但**stderr设为'ignore'是危险操作**——你将永远看不到子进程的崩溃日志。我们曾因此错过一个 C++ 插件的段错误（Segmentation Fault），排查三天才发现stderr被静默丢弃。'inherit'：将子进程的流直接继承父进程的process.stdin/stdout/stderr。效果等同于在终端直接运行命令。这在 CLI 工具开发中很常见（如npx create-react-app），但在服务器环境中应绝对避免——它会让子进程的日志混入主进程日志，破坏日志结构化，且inherit的stdout无法被.on('data')监听，失去流控能力。
最强大的是数组形式：stdio: ['pipe', 'pipe', 'pipe', 'ipc']。前三个是标准流，第四个'ipc'是为fork额外开启的 IPC 通道。你可以这样玩：
const child = spawn('node', ['worker.js'], { stdio: ['pipe', 'pipe', 'pipe', 'ipc'] // 索引 3 是 ipc }); child.send({ cmd: 'start', config: { timeout: 5000 } }); // 通过 ipc 发送 child.on('message', (msg) => console.log('Worker says:', msg)); // 监听 ipc 消息实操心得：永远为
stdout和stderr显式配置stdio，并立即.on('data')或.pipe()。哪怕只是child.stdout.on('data', () => {}); child.stderr.on('data', console.error);。这是防止子进程挂起的最低成本防护。
3.2detached模式：真·脱离还是假·脱离？别被名字骗了
detached: true常被误解为“让子进程完全独立，父进程退出后它还能活”。真相是：它只是让子进程脱离父进程的控制终端（TTY），并将其放入新的进程组（Process Group）。子进程依然受父进程生命周期影响——如果父进程异常崩溃（未调用child.unref()），子进程会收到SIGHUP信号并退出（除非子进程自己捕获并忽略SIGHUP）。
真正的“守护进程”需要三步：
spawn(..., { detached: true })child.unref()：解除子进程对父进程事件循环的引用，父进程可正常退出而不等待子进程。child.stdin.unref(); child.stdout.unref(); child.stderr.unref();：解除所有标准流的引用，确保子进程不依赖父进程的任何资源。
但即便如此，子进程仍可能因SIGPIPE（当它向已关闭的管道写入时）或SIGUSR2（某些 Node.js 版本的调试信号）而意外退出。所以，生产环境的守护进程，必须在子进程中主动捕获关键信号：
// worker.js process.on('SIGHUP', () => console.log('Ignoring SIGHUP')); process.on('SIGINT', () => { /* 清理资源，优雅退出 */ process.exit(0) }); process.on('SIGTERM', () => { /* 同上 */ process.exit(0) });我们曾部署一个detached的日志归档进程，因未unref()标准流，父进程重启时子进程被强制终止，导致当日日志全部丢失。教训是：detached是起点，不是终点；unref()是必选项，不是可选项。
3.3 信号控制：kill()不是“杀死”，而是“发送信号”
child.kill()方法名极具误导性。它并不直接终止进程，而是向子进程发送一个信号（默认SIGTERM）。子进程是否退出、如何退出，完全取决于它自身对信号的处理逻辑。
SIGTERM：请求终止，子进程可捕获并执行清理（如关闭数据库连接、保存状态），然后process.exit()。这是最友好的方式。SIGKILL：强制终止，无法被捕获或忽略，进程立即消失。这是最后手段。SIGUSR1/SIGUSR2：用户自定义信号，常用于触发子进程的特定行为（如node --inspect的SIGUSR1触发调试器启动）。
关键陷阱：child.kill()返回true仅表示信号成功发送，不代表子进程已退出。你必须监听child.on('exit')或child.on('close')来确认。更糟的是，如果子进程是 shell 脚本，SIGTERM可能只杀死 shell，而 shell 启动的真正子进程（如ffmpeg）变成孤儿进程继续运行！解决方案是使用kill -TERM -PID（负号表示发送给整个进程组）：
const child = spawn('sh', ['-c', 'ffmpeg -i input.mp4 output.avi']); // 正确终止整个进程组 process.kill(-child.pid, 'SIGTERM');注意：
child.pid是子进程的 PID，-child.pid是进程组 ID（PGID）。在 Linux 上，spawn创建的子进程默认与其父进程同属一个进程组，所以-child.pid就是它的 PGID。这是确保“连根拔起”的唯一可靠方法。
4. 实操过程与核心环节实现：从零搭建一个健壮的子进程管理器
4.1 基础封装：一个防崩、防漏、防失控的SafeSpawn
直接裸用spawn风险极高。我们封装了一个SafeSpawn类，它解决了三大痛点：1）子进程意外退出无感知；2）输出流未监听导致阻塞；3）超时未结束被遗忘。以下是核心代码（已脱敏，可直接复用）：
class SafeSpawn { constructor(command, args = [], options = {}) { this.command = command; this.args = args; this.options = { timeout: 30000, // 默认 30s 超时 maxBuffer: 1024 * 1024, // 1MB 缓冲 stdio: ['pipe', 'pipe', 'pipe'], ...options }; this.child = null; this.timeoutId = null; this.isKilled = false; } exec() { return new Promise((resolve, reject) => { try { this.child = spawn(this.command, this.args, this.options); } catch (err) { return reject(new Error(`Spawn failed: ${err.message}`)); } // 1. 必须监听 stdout/stderr，防止阻塞 const stdoutChunks = []; const stderrChunks = []; this.child.stdout.on('data', (chunk) => stdoutChunks.push(chunk)); this.child.stderr.on('data', (chunk) => stderrChunks.push(chunk)); // 2. 设置超时 this.timeoutId = setTimeout(() => { if (this.child && !this.child.killed) { this.isKilled = true; // 发送 SIGTERM 到整个进程组 try { process.kill(-this.child.pid, 'SIGTERM'); } catch (e) { // 进程可能已退出，忽略 } } }, this.options.timeout); // 3. 监听退出事件 this.child.on('exit', (code, signal) => { clearTimeout(this.timeoutId); if (this.isKilled) { return reject(new Error(`Process timed out after ${this.options.timeout}ms`)); } if (code !== 0) { const stderr = Buffer.concat(stderrChunks).toString(); return reject(new Error(`Command failed with code ${code}: ${stderr}`)); } const stdout = Buffer.concat(stdoutChunks).toString(); resolve({ stdout, stderr, code, signal }); }); // 4. 监听错误事件（如 ENOENT） this.child.on('error', (err) => { clearTimeout(this.timeoutId); reject(new Error(`Spawn error: ${err.message}`)); }); }); } kill(signal = 'SIGTERM') { if (this.child && !this.child.killed) { try { process.kill(-this.child.pid, signal); } catch (e) { // 忽略，进程可能已退出 } this.isKilled = true; } } } // 使用示例 async function runFfmpeg() { const safeSpawn = new SafeSpawn('ffmpeg', [ '-i', 'input.mp4', '-c:v', 'libx264', '-y', 'output.mp4' ], { timeout: 60000 }); try { const result = await safeSpawn.exec(); console.log('FFmpeg done:', result.stdout); } catch (err) { console.error('FFmpeg failed:', err.message); safeSpawn.kill('SIGKILL'); // 强制清理 } }这个封装的价值在于：它把所有“应该做但容易忘”的事情固化成了契约。每次调用exec()，你都默认获得了超时保护、流监听、错误聚合和进程组清理。它不是炫技，而是把运维常识变成了代码契约。
4.2fork进阶：IPC 通信的健壮模式与错误隔离
fork的 IPC 通道虽强大，但若不加防护，极易因消息格式错误或频率过高而崩溃。我们采用“信封协议”（Envelope Protocol）来加固：
- 信封结构：每条 IPC 消息都是
{ type: 'TASK_START', payload: {...}, id: 'uuid' }。type字段用于路由，id用于追踪和去重。 - 背压控制：Worker 进程在
process.on('message')中，对高频消息进行节流（throttle）或队列化（queue），避免 V8 堆溢出。 - 错误隔离：Worker 进程用
try...catch包裹process.on('message')的 handler，并将未捕获错误通过process.send({ type: 'ERROR', error: e.stack })发回 Master。Master 收到ERROR消息后，记录日志并worker.kill()重启。
Worker 端核心逻辑：
// worker.js process.on('message', (msg) => { if (msg.type === 'TASK_START') { try { const result = doHeavyWork(msg.payload); process.send({ type: 'TASK_DONE', id: msg.id, result }); } catch (e) { // 错误必须序列化为字符串，因为 Error 对象不能跨进程传输 process.send({ type: 'ERROR', id: msg.id, error: e.stack || String(e) }); } } }); // 主动监控自身健康 setInterval(() => { if (process.memoryUsage().heapUsed > 200 * 1024 * 1024) { // 200MB process.send({ type: 'HEALTH_WARN', memory: process.memoryUsage() }); } }, 5000);Master 端监听与恢复：
const worker = fork('./worker.js'); worker.on('message', (msg) => { if (msg.type === 'ERROR') { console.error(`Worker error for task ${msg.id}:`, msg.error); // 记录错误，然后重启 worker worker.kill(); worker = fork('./worker.js'); } else if (msg.type === 'HEALTH_WARN') { console.warn('Worker memory high:', msg.memory.heapUsed); } }); // 监听 worker 异常退出 worker.on('exit', (code, signal) => { console.error(`Worker exited with code ${code}, signal ${signal}`); // 自动重启 worker = fork('./worker.js'); });这套模式让我们在日均 500 万次任务分发中，Worker 崩溃率低于 0.001%，且每次崩溃都能精准定位到具体任务和错误堆栈。
4.3 调试实战：用strace和node --inspect定位子进程疑难杂症
当子进程表现诡异（如卡住、无输出、随机退出），日志往往不够用。这时需要深入系统层面：
strace跟踪系统调用：在 Linux 上，strace -f -p <pid>可实时查看进程及其子进程的所有系统调用。例如，发现子进程卡在read(0, ...)，说明它在等待stdin输入；卡在wait4(-1, ...)，说明它在等待子子进程；卡在epoll_wait，说明它在事件循环中空转。我们曾用strace发现一个spawn('python', [...])卡在connect()，原因是 Python 脚本试图访问一个 DNS 解析失败的域名，而spawn默认继承了父进程的timeout，导致无限等待。node --inspect调试fork子进程：fork会自动透传--inspect参数，但端口会冲突（默认 9229）。解决方案是动态分配端口：const inspector = require('inspector'); const session = new inspector.Session(); session.connect(); session.post('Inspector.enable'); session.post('Runtime.enable'); // 获取可用端口 const port = await getAvailablePort(); const worker = fork('./worker.js', [], { execArgv: [`--inspect=${port}`] }); console.log(`Worker inspector available at http://localhost:${port}`);内存快照对比：用
process.memoryUsage()在关键节点打点，或用node --inspect的 Memory 面板录制 Heap Snapshot。我们曾发现exec的buffer预分配导致内存虚高，而spawn的Stream内存恒定，这直接指导了 API 选型。
调试不是玄学，是系统性排除法。strace看系统层，--inspect看 V8 层，memoryUsage()看应用层，三者结合，99% 的子进程问题都能定位。
5. 常见问题与排查技巧实录：那些年踩过的坑，都成了我的 checklist
5.1 经典报错速查表
| 报错信息 | 根本原因 | 解决方案 | 我的实测经验 |
|---|---|---|---|
Error: spawn ENOENT | 找不到可执行文件。spawn('ffmpeg')失败，因为ffmpeg不在PATH中，或路径含空格未转义 | 1) 用绝对路径spawn('/usr/local/bin/ffmpeg', [...])；2) 或spawn('sh', ['-c', 'ffmpeg -i ...'])交由 shell 查找 | 我们曾因 Docker 镜像里ffmpeg装在/opt/ffmpeg/bin/而PATH未更新，导致ENOENT。后来统一用which ffmpeg获取绝对路径，再spawn。 |
Error: write EPIPE | 子进程已退出，父进程还往stdin写数据 | 1) 在child.on('close')后停止写入；2)stdin.write()前检查child.stdin.writable | 这个错误常出现在spawn('grep')后，grep因无匹配项快速退出，父进程还在stdin.write()。现在我们写入前必加if (child.stdin.writable) child.stdin.write(...)。 |
Error: read ECONNRESET | 子进程崩溃，stdout管道被重置 | 1) 监听child.on('error')；2) 在child.on('exit')中检查code和signal | 这通常意味着子进程 Segmentation Fault。用strace -f -p <pid>捕获崩溃瞬间的系统调用，或在子进程中process.on('SIGSEGV', ...)。 |
Error: Cannot enqueue Handshake after already enqueuing a Handshake | MySQL 连接池在子进程中复用，导致握手冲突 | 绝对禁止在子进程中复用父进程的数据库连接池。子进程必须创建自己的连接池 | 我们曾让fork的 Worker 复用 Master 的 MySQL 连接，结果并发一高就握手失败。现在 Worker 启动时，createPool({...})创建全新池。 |
5.2 高频陷阱与独家避坑技巧
陷阱 1：
spawn的cwd选项被忽略spawn('ls', [], { cwd: '/tmp' })本意是让ls在/tmp下执行，但如果你传入的命令是./script.sh，而script.sh里有cd /home，那么cwd就失效了。cwd只影响子进程启动时的初始工作目录，不影响其内部的cd命令。解决方案：要么用绝对路径spawn('/tmp/script.sh')，要么在命令中显式spawn('sh', ['-c', 'cd /tmp && ./script.sh'])。陷阱 2：
fork的execArgv透传不完整fork('./worker.js', [], { execArgv: ['--max-old-space-size=4096'] })，你以为 Worker 会获得 4GB 堆内存，但实际可能只有默认的 1.4GB。原因是execArgv只透传给node进程，而worker.js里require('child_process').fork()启动的孙进程，不会继承这个参数。execArgv只对直接fork的子进程生效，对子进程再fork的孙进程无效。解决方案：在 Worker 启动孙进程时，手动传入execArgv：fork('./grandson.js', [], { execArgv: process.execArgv })。陷阱 3：Windows 下的
spawn路径分隔符spawn('C:\\Program Files\\ffmpeg\\bin\\ffmpeg.exe', [...])在 Windows 上会失败，因为spawn内部用空格分割参数，而路径中的空格被误认为分隔符。Windows 下必须用spawn('cmd', ['/c', 'C:\\Program Files\\ffmpeg\\bin\\ffmpeg.exe', '-i', 'input.mp4'])。或者，用cross-spawn这个库，它自动处理跨平台路径和空格。独家技巧：用
ps命令验证进程树
当怀疑子进程未正确detached或kill()未生效时，不要猜，用ps看真实进程树：# Linux/macOS ps -o pid,ppid,pgid,sid,comm -forest | grep -A5 -B5 node # 查看 PID 为 1234 的进程及其子进程 pstree -p 1234如果
pstree显示你的子进程挂在node下，说明detached: true未生效；如果kill -TERM -1234后子进程还在，说明kill未发给进程组。眼见为实，这是最可靠的验证方式。
5.3 性能压测与容量规划：子进程不是免费的午餐
子进程消耗的是操作系统资源：PID、文件描述符、内存、CPU 时间片。一个spawn调用，至少消耗 1 个 PID、3 个文件描述符（stdin/stdout/stderr）、几 MB 内存。在高并发场景下，必须做容量规划：
- PID 限制：Linux 默认
ulimit -u是 1024，即单用户最多 1024 个进程。spawn一个子进程就占一个 PID。用ulimit -u 8192提升上限，或用pm2等进程管理器做限流。 - 文件描述符：每个
spawn占 3 个 fd。ulimit -n默认 1024，意味着最多同时spawn341 个子进程。用ulimit -n 65536提升，并在代码中process.setMaxListeners(0)防止 EventEmitter 监听器溢出。 - 内存与 CPU：
exec启动的 shell 进程比spawn的二进制进程多占 5~10MB 内存。fork的 Node.js 子进程，初始内存约 30MB。我们线上服务，spawn并发数控制在 50 以内，forkWorker 数固定为 CPU 核数，通过 Redis 队列削峰填谷。
压测时，我们用autocannon模拟 1000 QPS，监控top中的RES（物理内存）和%CPU。当RES持续增长不回落，说明有子进程泄漏；当%CPU达到 100% 且spawn延迟飙升，说明 CPU 成瓶颈，需增加 Worker 数或优化子进程逻辑。
6. 最后的体会：子进程管理，是 Node.js 开发者走向成熟的分水岭
写完这篇，我翻出三年前的代码，看到满屏的exec('some-command')和裸spawn，没有超时、没有错误处理、没有流监听。那时觉得“能跑就行”，直到第一次线上execOOM，主进程被系统 OOM Killer 杀死，整个服务雪崩。那一刻才明白，child_process模块不是 Node.js 的“附加功能”，而是它作为服务端运行时，与操作系统对话的“母语”。你无法回避它，只能学会用最精准的语法，表达最严谨的意图。
exec、spawn、fork的选择，从来不是语法糖的差异，而是你对系统资源、进程模型、错误传播路径的理解深度。一个detached: true的配置，背后是进程组、会话、控制终端的 Unix 哲学；一个stdio: ['pipe', 'pipe', 'pipe']的数组，背后是文件描述符、缓冲区、背压控制的底层机制；一次成功的process.kill(-pid, 'SIGTERM')，背后是信号传递、进程状态转换、僵尸进程回收的完整生命周期。
所以，别再把它当成“调用外部命令”的简单 API。把它当作一门微型操作系统课程，每一次spawn，都是你向内核发出的一次郑重请求；每一次 `child.on('exit')