Node.js通过child_process模块的detached选项间接实现进程组管理，使用spawn创建脱离的子进程，使其成为新进程组领导者，结合unref()允许父进程独立退出，并通过process.kill(-pid)向整个进程组发送信号，从而统一控制子进程生命周期，适用于后台服务、守护进程等场景，但需注意信号处理、平台差异、shell: true副作用及错误处理等问题，尤其在跨平台时需谨慎设计。
Node.js在进程组的操作上，说实话，并没有提供像底层C语言那样直接、细粒度的API，比如
setpgid或
setsid。我们更多的是通过管理子进程的生命周期和它们与父进程的关系，来间接达到操作“进程组”的效果。核心思路在于，当一个父进程启动多个子进程时，它们往往会形成一个逻辑上的集合，我们可以利用这一点来统一管理它们，比如在父进程退出时一并清理掉所有相关的子进程，或者向它们发送统一的信号。这感觉就像你在指挥一支小分队，而不是一个个单独的士兵。
解决方案
在Node.js中，要实现对进程组的间接操作，主要依赖于
child_process模块。最常见的场景是利用
spawn方法的
detached选项来创建一个新的会话（session），从而使子进程成为新的进程组的领导者。这样一来，父进程就可以在不被子进程阻塞的情况下继续执行，并且在需要时，通过向这个进程组的领导者PID发送负号信号，来影响整个进程组。
具体来说：
-
创建独立的进程组： 使用
child_process.spawn(command, args, { detached: true, stdio: 'ignore' })。detached: true
是关键，它会让子进程脱离父进程的控制终端，成为一个会话领导者，并创建一个新的进程组。stdio: 'ignore'
通常与detached: true
一起使用，避免子进程的输出流阻塞父进程，或者在父进程退出时导致子进程也因为终端关闭而退出。
-
获取进程组ID： 当
detached: true
时，child.pid
实际上就是新创建的进程组的ID（PGID）。 -
向进程组发送信号： 使用
process.kill(-child.pid, signal)
。注意这里的child.pid
前面带一个负号。这会向整个进程组发送指定的信号（例如SIGTERM
或SIGHUP
），而不仅仅是该子进程本身。
通过这种方式，我们可以在Node.js中模拟对进程组的控制，实现比如后台服务管理、守护进程的创建以及统一清理相关进程等功能。
为什么我们需要操作进程组？
在我看来，操作进程组的需求，往往源于对复杂应用生命周期的管理。想象一下，你有一个Node.js服务，它可能需要启动多个辅助进程，比如一个数据处理脚本、一个日志收集器或者一个定时任务。如果这些子进程只是简单地启动，那么当你的主服务（父进程）意外崩溃或者需要优雅退出时，这些子进程很可能就会变成“孤儿进程”，继续在后台运行，占用资源，甚至造成意想不到的问题。
我个人在项目里遇到过这样的情况：一个Node.js应用启动了一个FFmpeg进程进行视频转码，如果主应用被kill掉，FFmpeg进程却还在默默地消耗CPU。这时候，如果能把FFmpeg和它的所有子进程（如果有的话）都归到一个进程组里，那么当主应用退出时，我们就可以统一向这个进程组发送一个
SIGTERM信号，让它们都能干净地退出，而不是变成系统里的幽灵。
此外，对于需要创建守护进程（daemon）的应用，进程组的概念更是核心。一个真正的守护进程通常会脱离控制终端，成为一个会话领导者，拥有自己的进程组，这样它就不会因为终端关闭而受到影响。这不仅是系统资源管理的考量，更是为了应用的健壮性和可靠性。
Node.js中如何创建和管理一个简单的进程组？
创建一个简单的进程组并在Node.js中管理它，主要围绕
child_process.spawn的
detached选项展开。这里有个小例子，可以帮你理解：
const { spawn } = require('child_process');
const path = require('path');
// 假设我们有一个简单的子进程脚本，比如 child.js
// child.js 内容可能只是：
// setInterval(() => console.log(`Child process ${process.pid} running...`), 1000);
// process.on('SIGTERM', () => { console.log(`Child ${process.pid} received SIGTERM.`); process.exit(0); });
const childScriptPath = path.join(__dirname, 'child.js');
function startDetachedProcessGroup() {
console.log(`Parent process ${process.pid} starting...`);
// 启动一个脱离的子进程，它将成为新的进程组的领导者
const child = spawn(process.execPath, [childScriptPath], {
detached: true, // 关键：创建新的进程组
stdio: 'ignore' // 忽略标准输入输出，防止阻塞父进程
});
// 这一步很重要，unref() 允许父进程在子进程还在运行时退出
// 如果不调用 unref()，父进程会等待子进程退出
child.unref();
console.log(`Detached child process started with PID: ${child.pid}`);
console.log(`This PID (${child.pid}) is also the PGID of its new process group.`);
// 假设我们在一段时间后想要终止这个进程组
// 注意：这里我们使用 setTimeout 模拟一段时间后的操作
// 实际应用中，你可能需要存储 child.pid，并在某个事件触发时调用
setTimeout(() => {
console.log(`Parent process ${process.pid} sending SIGTERM to process group ${child.pid}...`);
try {
// 向整个进程组发送 SIGTERM 信号
process.kill(-child.pid, 'SIGTERM');
console.log(`SIGTERM sent to process group ${child.pid}.`);
} catch (error) {
console.error(`Error sending signal to process group ${child.pid}:`, error.message);
}
console.log(`Parent process ${process.pid} exiting.`);
process.exit(0);
}, 5000); // 5秒后尝试终止进程组
}
// 为了演示，我们先创建一个 child.js 文件
// 请手动创建 child.js 文件，内容如下：
/*
// child.js
setInterval(() => {
console.log(`Child process ${process.pid} running in group ${process.getpgid(process.pid)}...`);
}, 1000);
process.on('SIGTERM', () => {
console.log(`Child process ${process.pid} received SIGTERM. Exiting.`);
process.exit(0);
});
console.log(`Child process ${process.pid} started in group ${process.getpgid(process.pid)}.`);
*/
startDetachedProcessGroup();运行这个例子，你会看到父进程启动子进程后，可以立即执行后续代码，并在设定的时间后尝试终止子进程所在的整个进程组。
process.kill(-child.pid, 'SIGTERM')是这里的核心，它确保了信号是发给整个进程组，而不是仅仅一个进程。
进程组操作中常见的陷阱和注意事项有哪些？
坦白说，这块儿没有银弹，更多的是权衡和理解底层机制。在Node.js中操作进程组，虽然方便，但确实有一些常见的陷阱和需要注意的地方：
-
信号处理： 子进程必须正确处理接收到的信号。如果子进程没有为
SIGTERM
等信号设置处理器，它可能不会优雅地退出，而是被强制终止，这可能导致数据丢失或状态不一致。我见过很多Node.js子进程忘记添加process.on('SIGTERM', ...)，结果就是被强制退出，留下一个不干净的现场。 -
unref()
的重要性： 如上例所示，child.unref()
非常重要。如果没有它，即使子进程被detached
，父进程也可能会一直等待子进程退出，这与我们希望父进程能自由退出的初衷相悖。它告诉事件循环，如果这是唯一剩下的句柄，那么它可以退出。 -
平台差异： 进程组的概念在Unix-like系统（Linux, macOS）中非常成熟和常用，但在Windows上，其行为可能会有所不同。Windows有自己的进程和作业对象（Job Objects）管理机制，
detached: true
在Windows上通常意味着子进程会在一个独立的控制台窗口中运行，而不是像Unix-like系统那样创建一个新的会话和进程组。因此，process.kill(-pid)
在Windows上可能不会像在Unix-like系统上那样作用于整个进程组。在跨平台应用中，这一点尤其需要注意。 -
孤儿进程组： 如果进程组的领导者（即我们用
spawn
创建的那个child
）在没有正确清理其子进程的情况下退出，那么这个进程组中的其他进程就会变成孤儿进程，它们的父进程会变成init
（PID 1），并且它们会继续运行。虽然process.kill(-child.pid)
可以帮助我们清理，但如果信号发送失败或子进程未能响应，问题依然存在。 -
shell: true
的副作用： 如果你在spawn
选项中设置了shell: true
，那么实际上Node.js会先启动一个shell进程，然后由这个shell来执行你的命令。这意味着child.pid
将是shell的PID，而不是你真正想控制的命令的PID。在这种情况下，process.kill(-child.pid)
可能只会影响到shell进程，而不是由shell启动的实际命令。通常，为了精确控制，我们会避免shell: true
，直接执行命令。 -
错误处理和健壮性： 任何涉及到进程间通信和管理的，都需要健壮的错误处理。例如，当尝试向一个已经不存在的进程组发送信号时，
process.kill
会抛出错误，你需要捕获并处理这些错误。同时，考虑子进程启动失败、长时间无响应等情况。
总的来说，Node.js的进程组操作更多是一种“黑盒”式的间接控制。你需要对底层操作系统的进程管理有一定理解，才能更好地驾驭它，避免不必要的麻烦。
