必须手动调用client.close()，因Node.js进程退出不会自动释放MongoDB客户端持有的TCP连接池、心跳定时器等资源，若不显式关闭并await完成，这些后台任务将持续持有对象引用，阻止GC回收，导致内存泄漏和MaxListenersExceededWarning。
Node.js中MongoDB连接未关闭导致的内存泄漏
不显式调用 client.close()，应用退出时 MongoDB 客户端连接会持续占用 socket 和内存资源，尤其在开发阶段反复重启、或测试脚本执行后未清理，容易触发 MaxListenersExceededWarning 或 RSS 内存缓慢上涨——这不是“连接失败”，而是“连接滞留”。
为什么client.close()必须手动调用而非依赖进程退出
Node.js 进程退出时不会自动释放 MongoClient 实例持有的 TCP 连接池和监控定时器。驱动内部维护着多个后台任务（如心跳检测、服务器发现），若未主动关闭，这些任务会继续运行并持有引用，阻止 GC 回收，最终表现为内存泄漏。
-
client.close()是异步操作，需await确保真正释放资源；仅调用不等待，等同于没关 - 使用
mongoose时，mongoose.disconnect()才等价于原生驱动的client.close()；直接process.exit(0)会跳过所有清理逻辑 - 在 Express 应用中，
app.listen()启动后没有监听SIGINT/SIGTERM信号，就无法捕获 Ctrl+C 或 Kubernetes 的优雅终止指令
如何在应用关闭前安全调用client.close()
核心原则：把关闭逻辑绑定到进程生命周期信号，且确保它只执行一次、不被重复触发。
- 对原生
mongodb驱动：在client.connect()成功后，注册一次process.on('SIGINT', ...)和process.on('SIGTERM', ...) - 必须用
async匿名函数包装client.close()，并在await后再调用process.exit(0)，否则关闭未完成进程已退出 - 避免在
finally块中直接client.close()—— 如果connect()本身失败，client可能未定义，会抛出TypeError - 示例片段：
process.on('SIGINT', async () => {<br> console.log('Shutting down...');<br> if (client && client.topology?.connected) {<br> await client.close();<br> }<br> process.exit(0);<br>});
容易被忽略的边界情况
连接泄露常发生在你以为“已经关了”的地方：
- 测试脚本（如 Jest）中创建了
client，但没在afterAll()里await client.close()，每个 test suite 都会累积一个未关闭连接 - 使用
mongoose时混用mongoose.connect()和手动 newMongoClient，导致两套连接池并存，只关了一个 - 在 Kubernetes 环境下，
preStophook 超时（默认 30 秒）早于client.close()完成，容器被强制 kill，连接滞留 -
client.close({ force: true })可绕过等待，但会丢弃正在执行的写入操作，仅适用于紧急终止场景，不应作为常规手段
最危险的错觉是：控制台没报错、服务响应正常，就认为连接管理没问题。实际连接数可能已在后台悄悄涨到几百，直到 OOMKilled 才暴露问题。
