MongoDB示例中生产环境写入全局变量有何问题？

首先要明确：开发环境用全局变量不是什么通用最佳实践，只是针对开发环境特性做的专属适配方案，目的是解决实际开发痛点，且风险完全可控；而生产环境没有对应的痛点，用全局变量反而会引入不必要的隐患。

开发环境用全局变量的原因 #

• 本地开发时，Vite、Next.js这类工具都自带HMR（热模块替换）能力：每次修改代码保存，对应模块会被重新执行，但不会重启整个Node服务。如果把Mongo连接的promise存在模块作用域的变量里，每次热重载都会新建一个数据库连接，用不了几次就会打满Mongo的最大连接数，直接导致数据库连接失败。
• 把连接promise挂在global全局对象上的话，热重载只会重新执行模块代码，不会清空全局对象，已经创建好的连接会被持续复用，从根源上避免热重载打爆连接数的问题。
• 开发环境的服务只跑在本地机器上，只有开发者本人访问，哪怕全局变量被意外修改，重启下开发服务就能完全重置状态，不会造成任何实际损失，风险完全可控。

生产环境不建议用全局变量的核心原因 #

• 首先是完全没必要：生产环境没有HMR机制，服务启动后模块只会加载一次，把连接promise存在模块作用域里导出，所有引用这个模块的代码天然会复用同一个连接，完全能实现单例连接池的效果，根本不需要靠全局变量来保留状态。
• 其次是全局变量会引入很多生产环境特有的风险：
  • 状态泄露风险：如果服务部署在Serverless、边缘函数这类可能复用进程承载多请求的运行时上，全局变量是跨请求共享的，一旦代码逻辑不小心修改了全局变量上的内容，可能出现A用户的请求数据泄露给B用户的安全问题。
  • 连接泄漏风险：全局属性没有访问限制，任何模块的代码都能随意改写global._mongoClientPromise的值，一旦引用被意外覆盖，旧的数据库连接不会被正常回收，服务长时间运行后会耗尽数据库连接数，而且这类问题排查难度极高。
  • 可维护性差：全局变量打破了模块的作用域边界，后续迭代代码时，没法快速定位到底是哪段代码修改了全局连接的状态，出问题时排查链路会很长。

说白了这段代码的逻辑就是典型的环境适配：开发环境为了解决热重载的痛点，临时用全局变量做缓存，属于只在开发环境生效的权宜之计；生产环境没有这个痛点，自然不需要引入全局变量的额外风险。

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