Node.js垃圾回收器是否会清除全局变量属性？如何避免挂载的mongoose实例丢失？

推测是否成立 #

你的推测不成立。JavaScript的垃圾回收机制只会回收没有被任何引用指向的对象，只要你确实给global对象挂载了mongoose_instance属性，且没有手动删除该属性、也没有重新赋值global对象本身，这个属性对应的引用会一直存在，不会被GC主动清除。

生产环境报错的常见原因 #

• 模块加载顺序差异：开发、staging环境的启动/模块加载逻辑和生产环境不一致，出现controller代码执行时机早于全局挂载mongoose实例的代码的情况。本地开发的热重载逻辑、模块缓存策略都可能掩盖加载顺序问题，到了冷启动的生产环境问题就会暴露。
• 运行时作用域隔离：如果生产环境用了打包工具（webpack、rollup、esbuild等）或者ESM/CommonJS混合加载，你赋值的global和业务代码中访问的global可能不是同一个顶层对象，跨模块/跨作用域访问自然拿到undefined。
• 多进程隔离：如果生产环境用pm2等工具开启多进程模式，每个进程的global对象完全独立，你只在主进程挂载属性的话，工作进程访问时必然返回undefined。

解决方案 #

• 优先用单例模块替代全局挂载：这是最稳妥的方案。单独封装一个数据库连接模块，示例如下：

// db.js 单独文件
const mongoose = require('mongoose')
// 完成连接逻辑
mongoose.connect(/* 你的连接配置 */)
module.exports = mongoose

后续所有需要用数据库连接的地方直接const db = require('./db')即可，Node.js的模块本身就是单例，所有地方拿到的都是同一个实例，不存在加载顺序、作用域隔离的问题。

• 如果你一定要保留全局挂载的写法：调整启动顺序，在项目入口最顶部先完成数据库连接、给global.mongoose_instance赋值，之后再引入所有controller、路由等业务模块，确保所有访问该全局属性的代码执行时机都晚于赋值时机。
• 兼容顶层对象差异：把global替换为兼容性更好的globalThis，避免不同运行时、不同模块规范下顶层对象不统一的问题。

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