TopologyClosedError源于重复调用connect()或提前关闭连接；应全局单例复用连接，启动时一次connect并监听连接事件，禁用各处.close()和.disconnect()。
为什么TopologyClosedError总在异步操作里冒出来
因为你在每次数据库操作前都调用了 client.connect()，但没等上一次连接释放完就又发起新连接，或者更常见的是：连接对象被提前关闭了。Node.js 的 MongoDB 驱动（包括 Mongoose 底层）不允许对已关闭的拓扑（Topology）执行任何操作，一旦触发 client.close() 或进程异常退出，后续所有 findOne、save 等调用都会抛出 MongoError: Topology is closed, please connect。
别在每个函数里重复调用 connect()
Mongoose 和原生 MongoClient 都设计为「单例连接复用」——你应该只在应用启动时连接一次，之后所有模型操作都复用这个连接。反复调用 connect() 不仅不会新建有效连接，反而可能触发竞态，导致连接状态混乱。
常见错误写法：
async function validateUniqueUser(email) {
const client = new MongoClient(uri);
await client.connect(); // ❌ 每次都新建 client + connect
const user = await client.db('test').collection('users').findOne({ email });
await client.close(); // ❌ 这里关掉后，下个请求就崩了
return !user;
}
正确做法：
- 全局声明一个
mongoose实例或client，在app.js或入口文件中一次性connect() - 确保连接成功后再启动 HTTP 服务（比如 Express 的
app.listen放在.then()里） - 所有路由/业务函数直接使用已建立的
Model或db对象，不自己管理连接生命周期
useUnifiedTopology: true 是必须项，但不是万能解药
这个选项关闭旧版服务器发现机制，启用新版拓扑监控，能缓解部分断连误报，但它不能掩盖连接被主动关闭的事实。如果你仍看到 Topology was destroyed，大概率是代码里某处偷偷执行了 client.close() 或 mongoose.disconnect()。
排查要点：
- 搜索整个项目中的
.close(、.disconnect(、mongoose.connection.close( - 检查测试脚本、CLI 命令、定时任务是否在执行完后错误地关闭了连接
- 确认没有在
process.on('SIGINT')之外的地方提前调用关闭逻辑 - 如果用了
server: { auto_reconnect: true }（Mongoose v5 及以前），请升级到 v6+ 并改用retryWrites: true和连接事件监听
连接失败时别静默吞掉错误
很多开发者把 mongoose.connect() 包在 try/catch 里却不处理失败，结果连接根本没建起来，后续所有操作都在一个“假连接”上运行，直到第一个查询才暴露 TopologyClosedError。
务必显式监听连接事件：
mongoose.connect(uri, {
retryWrites: true,
maxPoolSize: 10,
minPoolSize: 2
}).then(() => {
console.log('✅ MongoDB connected');
}).catch(err => {
console.error('❌ MongoDB connection failed:', err);
process.exit(1);
});
mongoose.connection.on('error', (err) => {
console.error('? MongoDB connection error:', err);
});
mongoose.connection.on('disconnected', () => {
console.warn('⚠️ MongoDB disconnected');
});
真正麻烦的不是连接不上，而是连接看起来“成功”了，实际却卡在中间状态——这种问题往往要靠日志和连接事件钩子才能揪出来。
