不使用Mongoose操作MongoDB时，是否必须为每个连接实例调用close()方法？

核心结论 #

常规长期运行的业务服务场景下，完成单次数据库调用后完全不需要主动为连接实例调用close()方法。

需要主动调用close()的场景 #

• 一次性运行的短生命周期脚本：比如临时数据迁移任务、单次离线批处理脚本，在所有数据库操作全部执行完成、拿到最终执行结果后，主动调用close()可以避免进程因为等待连接池空闲挂起，也能防止进程提前退出导致未完成的数据库操作异常中断。
• 资源配额严格受限的临时任务：如果运行环境对文件句柄数、TCP连接数有硬性配额限制，且确认后续较长时间不会再有数据库交互需求，主动关闭连接可以及时释放占用的系统资源。

不主动调用close()的实际优势 #

• 复用驱动自带的连接池能力，省去反复建连的性能损耗：MongoDB官方驱动和Mongoose的设计逻辑一致，默认实现了长连接池机制，保持长连接复用的场景下，单次数据库操作的响应延迟远低于每次操作完成后断连、下次操作重新握手建连的模式。
• 降低MongoDB服务端的连接压力：短时间频繁新建、断开连接会在服务端产生大量处于TIME_WAIT状态的TCP连接，不仅会占用服务端资源，严重时还会触发服务端的连接数阈值限流，主动维持长连接能从根源上规避这类问题。

不主动调用close()的潜在风险 #

注：不主动调用close()本身不存在直接的安全层面问题，所有连接权限校验、传输加密校验都是连接建立阶段完成的，和是否主动断开连接没有关联。
真实存在的风险主要集中在资源配置不当的场景：

• 长期运行的服务如果没有合理配置连接池的最大连接数上限，可能会出现连接数无节制增长，最终打满MongoDB服务端的允许连接阈值，导致后续业务请求无法正常建立连接。
• 进程退出时没有触发连接的优雅关闭逻辑，可能导致最后几批正在执行的写操作没有被服务端确认就中断，出现数据写入不一致的问题——这类问题本质是进程退出逻辑的缺陷，并非日常服务运行时不主动调用close()导致的。
• 多实例共用同一个MongoDB集群时，如果没有统一规划每个服务实例的连接池大小，所有实例的总连接数超过MongoDB的承载上限后，会触发全局的连接拒绝异常。

内容的提问来源于stack exchange，提问作者pasoc30