MongoDB 客户端连接一旦中断，并不会自动恢复。许多开发者误以为配置了 reconnectTries 就能高枕无忧，但一旦遭遇 topology was destroyed 错误，后续所有操作都会彻底瘫痪，只能被迫手动重启进程。
MongoDB 客户端默认不会自动重建已销毁的拓扑连接，一旦出现 topology was destroyed 错误，后续所有操作均会失败，必须人工干预或重启进程才能恢复。
为什么 reconnectTries 和 reconnectInterval 不起作用？
这两个选项仅对“初始连接失败”有效，无法应对连接建立后因网络中断、mongod 宕机等导致的拓扑崩溃。当连接池内部状态变为 destroyed 时，驱动会直接拒绝所有新请求，不再尝试重连。
reconnectTries: 60只在MongoClient.connect()首次执行失败时重试 60 次- 运行过程中拓扑被破坏（例如 mongod 停机 35 秒）后，
reconnectTries根本不会触发 - 错误日志中反复出现
[MongoError: topology was destroyed]就是这一状态的明确信号
如何监听并主动重建连接？
被动等待无法解决问题，必须监听客户端事件，在拓扑断开时主动调用 client.close() 并重新执行 connect()，否则旧 client 实例会永久卡死。
- 监听
client.on('serverClosed', () => {...})或更通用的client.on('topologyClosed', () => {...}) - 不要只依赖
error事件：许多断连不会抛出错误，而是让后续操作直接报topology was destroyed - 重建前务必先执行
await client.close()，否则connect()会复用已损坏的实例 - 重连逻辑需加入防抖措施，避免在断连期间频繁触发多次重建
生产环境推荐的连接初始化模式
将连接封装成可重入函数，配合指数退避与状态标记，比依赖驱动内置重试更可控。
let client = null;
let isConnecting = false;
async function connectWithRetry() {
if (client && client.topology?.state === 'connected') return client;
if (isConnecting) return new Promise(r => setTimeout(() => r(connectWithRetry()), 100));
isConnecting = true;
try {
if (client) await client.close();
client = new MongoClient(uri, {
reconnectTries: 1, // 初始连接失败时只试 1 次，由外层控制重试
reconnectInterval: 1000
});
await client.connect();
console.log('MongoDB connected');
} catch (err) {
console.error('MongoDB connect failed:', err);
await new Promise(r => setTimeout(r, 2000)); // 指数退避起点
return connectWithRetry();
} finally {
isConnecting = false;
}
return client;
}
- 每次调用
connectWithRetry()都能确保获得一个健康的新client reconnectTries: 1是关键：禁用驱动内部重试，将控制权收归自己- 避免在路由层直接使用
client.db().collection()：应封装为 service 方法，内部自动处理连接异常
真正棘手的并非连不上，而是连接后又断开，断开后却看似仍在连接——topology was destroyed 后 client 对象依然存在，但所有方法调用都会静默失败。必须通过 client.topology?.state 或定期执行 client.db().admin().ping() 主动探测，不能仅凭“它没报错”就认为一切正常。
