服务优雅重启的关键是主动释放模块持有的操作系统资源，需模块提供close/destroy等清理接口，并在SIGTERM/SIGINT信号时统一执行Promise.allSettled确保全部清理完成。
CommonJS 模块本身不直接管理操作系统级资源（如文件句柄、数据库连接、网络 socket），但模块导出的对象或初始化过程中创建的实例常常持有这些资源。服务优雅重启时，关键不是“卸载模块”，而是主动释放模块所创建并长期持有的资源——这需要开发者在模块设计阶段就预留清理入口，并在进程退出前统一触发。
模块自身提供显式清理接口
每个可能持有外部资源的模块，应暴露一个可调用的 close()、destroy() 或 teardown() 方法：
- 数据库客户端模块：导出
closeConnection()，内部调用pool.end()或client.destroy() - 定时任务模块：导出
stopHeartbeat()，内部clearInterval(this.timer) - WebSocket 客户端模块：导出
disconnect()，含发送关闭消息 + 清理监听器 +socket.close() - 日志写入器模块：导出
flushAndClose()，确保缓冲日志落盘后关闭文件流
进程退出前统一触发所有清理逻辑
利用 Node.js 的退出信号监听机制，在主进程收到 SIGTERM（K8s 停止、PM2 重启）或 SIGINT（Ctrl+C）时，按顺序执行所有已注册的清理函数：
- 使用
process.on('beforeExit', ...)不可靠（不捕获信号，且可能在异步未完成时触发） - 推荐监听
'SIGTERM'和'SIGINT'，设置标志位防止重复执行 - 将各模块的清理函数集中注册到一个数组或 Map 中，例如：
cleanupTasks.push(db.closeConnection.bind(db)) - 清理函数支持 Promise，用
Promise.allSettled(cleanupTasks.map(fn => fn()))确保全部尝试执行，不因某个失败而中断其余
配合模块缓存机制避免残留引用
CommonJS 缓存（require.cache）本身不会阻止 GC，但若模块导出的对象被全局变量、事件监听器或闭包长期持有，资源就无法释放：
立即学习“Java免费学习笔记（深入）”；
- 清理完成后，手动将模块从缓存中移除（仅限开发/调试场景）：
delete require.cache[require.resolve('./db.js')] - 更重要的是：确保清理函数执行后，不再有代码引用该模块导出的资源对象（如清空全局
app.db引用） - 避免在模块顶层直接执行副作用（如
fs.createWriteStream()），应封装进初始化函数，由上层控制生命周期
借助工具库简化流程
可引入轻量库辅助资源生命周期管理：
-
exit-hook：注册同步/异步退出钩子，自动处理SIGTERM/SIGINT -
graceful-shutdown：提供超时控制、状态检查、多阶段关闭（如先停 HTTP server，再关 DB） - 自定义
ResourceManager类：统一注册资源与销毁函数，支持分组、依赖顺序、超时熔断
