Node.js中常见进程信号包括SIGINT（用户中断，如Ctrl+C）、SIGTERM（请求终止，用于优雅停机）、SIGHUP（重新加载配置）、SIGUSR1/SIGUSR2（自定义用途）、SIGKILL（强制终止，不可捕获）和SIGSTOP（暂停进程，不可捕获）。其中，SIGINT和SIGTERM可用于实现优雅停机，通过监听这些信号，停止接收新请求、完成现有任务、清理资源后安全退出；而SIGHUP和SIGUSR1/2可扩展用于热重载或状态监控等场景。处理时需避免阻塞操作、慎用process.exit()、设置超时机制，并统一管理退出逻辑，确保应用在容器化环境中稳定运行。
Node.js中操作进程信号主要通过内置的
process对象实现，它允许开发者监听和响应操作系统发送给进程的各种信号，例如中断信号（
SIGINT）、终止信号（
SIGTERM）等。这对于实现应用的优雅停机、配置热重载或处理特定系统事件至关重要。
在Node.js中，要处理进程信号，最直接的方式就是使用
process.on()方法来监听特定的信号事件。例如，你可以监听
SIGINT（通常是用户按下Ctrl+C触发）或
SIGTERM（由
kill命令或容器编排系统发送）信号，并在接收到这些信号时执行清理工作，比如关闭数据库连接、保存未完成的数据或停止HTTP服务器，确保应用程序能够平稳、安全地退出，而不是突然崩溃。
Node.js中常见的进程信号有哪些，它们各自的用途是什么？
在Node.js的世界里，我们与操作系统打交道，进程信号就是操作系统和我们应用之间的一种“悄悄话”。了解这些信号，对于构建健壮的Node.js应用来说，我觉得是基础中的基础。
-
SIGINT
(Interrupt Signal)：这是我们最常遇到的信号之一，通常由用户在终端按下Ctrl+C
时发出。它的本意是请求程序中断当前操作。在Node.js应用中，监听SIGINT
是实现优雅退出的首要步骤。如果你不处理它，Node.js进程默认会直接退出。 -
SIGTERM
(Termination Signal)：这个信号是操作系统或进程管理器（比如kill
命令，或者Docker、Kubernetes这类容器编排系统）请求进程终止的“标准”方式。它比SIGINT
更“正式”一些，意味着“请你自行清理后退出”。在生产环境中，SIGTERM
是实现优雅停机的核心。 -
SIGHUP
(Hang Up Signal)：这个信号最初设计是在终端关闭时发送给进程的。但现在，它更多地被用于通知守护进程（daemon）重新加载配置文件。比如，你修改了某个配置，发送SIGHUP
，应用就可以在不重启的情况下加载新配置。当然，这需要你在代码里明确实现这个逻辑。 -
SIGUSR1
/SIGUSR2
(User-defined Signals)：这两个信号是留给开发者自定义用途的。它们没有预设的行为，你可以用它们来触发特定的应用逻辑，比如日志级别切换、内部状态报告等，非常灵活。 -
SIGKILL
(Kill Signal)：这是一个“不讲道理”的信号。它会强制立即终止进程，不给进程任何清理的机会。你的Node.js应用无法捕获或忽略SIGKILL
。这意味着，如果你的应用收到SIGKILL
，它会立刻死掉，没有任何商量的余地。这通常是作为最后的手段，当进程无响应时才使用。 -
SIGSTOP
(Stop Signal)：这个信号会暂停进程的执行，但不会终止它。进程处于暂停状态，直到收到SIGCONT
信号才会恢复。同样，SIGSTOP
也无法被捕获或忽略。
我个人觉得，对
SIGINT和
SIGTERM的妥善处理，是衡量一个Node.js应用是否“专业”的重要标准。至于
SIGHUP和
SIGUSR*，则能让你在特定场景下玩出更多花样。
如何在Node.js应用中实现优雅停机（Graceful Shutdown）？
优雅停机，说白了就是让你的应用在被要求退出时，能把手头的工作做完，把该关的都关掉，再体面地离开。这听起来简单，但实际操作起来，尤其是在异步的世界里，还是有些门道的。
一个典型的Node.js应用，在收到
SIGINT或
SIGTERM信号后，应该：
-
停止接受新的请求：对于HTTP服务器来说，这意味着调用
server.close()
。这样，新的连接就不会进来，但现有的连接会继续处理。 - 完成现有请求/任务：等待所有正在处理的HTTP请求完成，或者等待正在进行的数据库操作、消息队列消费任务结束。
- 清理资源：关闭数据库连接池、Redis客户端、文件句柄、WebSocket连接等所有外部资源。
- 最终退出：在所有清理工作完成后，安全地退出进程。
这是一个简单的实现示例：
const http = require('http');
let connections = new Set(); // 用于追踪所有活跃的连接
const server = http.createServer((req, res) => {
// 模拟一个需要一些时间处理的请求
setTimeout(() => {
res.writeHead(200, { 'Content-Type': 'text/plain' });
res.end('Hello Node.js Graceful Shutdown!\n');
}, 500); // 假设处理需要500ms
});
server.on('connection', connection => {
connections.add(connection);
connection.on('close', () => connections.delete(connection));
});
server.listen(3000, () => {
console.log('Server running at http://localhost:3000/');
});
// 优雅停机逻辑
const gracefulShutdown = () => {
console.log('Received kill signal, shutting down gracefully...');
// 1. 停止接受新的请求
server.close(() => {
console.log('Closed out remaining connections.');
// 2. 所有连接都已关闭，可以安全退出
process.exit(0);
});
// 如果有活跃连接，给它们一些时间完成
// 否则，server.close()会立即回调
if (connections.size > 0) {
console.log(`Waiting for ${connections.size} connections to close...`);
// 设置一个超时，防止某些连接永远不关闭
setTimeout(() => {
console.warn('Forcefully shutting down due to timeout. Not all connections closed.');
connections.forEach(conn => conn.destroy()); // 强制关闭剩余连接
process.exit(1); // 退出码非0表示非正常退出
}, 10000); // 10秒超时
} else {
// 如果没有活跃连接，直接退出
process.exit(0);
}
};
// 监听终止信号
process.on('SIGTERM', gracefulShutdown);
process.on('SIGINT', gracefulShutdown);
// 监听未捕获的异常，这也很重要，避免应用在意外情况下崩溃
process.on('uncaughtException', (err) => {
console.error('Uncaught Exception:', err);
// 在生产环境中，这里通常会记录错误并尝试优雅退出
// 但为了避免进程卡死，有时会选择立即退出或在短暂清理后退出
gracefulShutdown();
});
process.on('unhandledRejection', (reason, promise) => {
console.error('Unhandled Rejection at:', promise, 'reason:', reason);
// 同样，这里也应该进行错误记录和优雅退出
gracefulShutdown();
});这里我用了一个
Set来追踪活跃连接，这在处理HTTP服务器的优雅停机时非常实用。
server.close()只会停止接受新连接，但不会强制关闭现有连接。我们得给现有连接一个完成请求的机会。如果超时了，我们可能就得“狠心”地强制关闭它们，然后退出。
处理进程信号时，Node.js有哪些需要注意的陷阱或最佳实践？
处理进程信号这事儿，看似简单，但实际操作中还是有些坑需要避开，也有一些实践能让你的应用更稳健。
- 不要在信号处理器中执行阻塞操作：这是个大忌。信号处理器应该尽可能轻量和快速。如果你在里面做了同步的、耗时的操作（比如同步读写大文件，或者复杂的CPU密集型计算），那你的应用就可能卡死，无法响应其他信号，甚至无法正常退出。所有清理工作都应该是异步的。
-
process.exit()
的慎用：process.exit()
会立即终止Node.js进程，跳过事件循环中所有未完成的异步操作。这意味着，如果你在调用process.exit()
之前还有数据库写入、文件保存等异步任务，它们可能就不会执行了。通常，我们应该让Node.js的事件循环自然地清空，或者至少确保所有关键的异步清理任务完成后再退出。只有在确定所有清理工作都已完成，或者在非常紧急的情况下（例如，超时强制退出），才应该调用process.exit()
。 -
统一的停机逻辑：我建议你把所有的清理和退出逻辑封装到一个函数里（就像上面示例中的
gracefulShutdown
），然后在所有需要的地方调用它。这样可以避免逻辑分散，减少重复代码，也更容易维护。 - 设置合理的超时：优雅停机不是无限等待。如果你的应用在收到信号后，清理工作迟迟不能完成，那就需要一个超时机制来强制退出。这可以防止应用在某些极端情况下（比如外部服务无响应）无限期地挂起，影响整个系统的稳定性。
-
区分退出码：
process.exit(0)
表示正常退出，而process.exit(1)
或其它非零值则表示异常退出。在脚本或容器环境中，这个退出码非常重要，它可以告诉父进程或编排系统你的应用是否成功完成任务。 -
考虑
uncaughtException
和unhandledRejection
：虽然它们不是进程信号，但在应用健壮性方面，它们和信号处理一样重要。一个未捕获的异常可能导致你的应用在没有任何警告的情况下崩溃。妥善处理这些情况，比如记录日志并尝试优雅退出，能大大提高应用的稳定性。 -
在容器化环境中的考量：在Docker或Kubernetes这样的容器环境中，
SIGTERM
是容器编排系统停止容器的标准信号。确保你的Node.js应用能正确响应SIGTERM
，并执行优雅停机，这对于容器的平稳升级和部署至关重要。如果你的应用不处理SIGTERM
，容器可能在超时后直接发送SIGKILL
，导致数据丢失或状态不一致。 -
避免重复的信号处理：如果你多次调用
process.on('SIGTERM', handler)，那么每次收到SIGTERM
时，所有的处理器都会被执行。这通常不是你想要的。如果你需要替换处理器，应该先用process.removeListener()
移除旧的。但在大多数优雅停机场景中，一个统一的处理器就足够了。
