认证超时主因是重复auth handshake，而非网络慢；authSource配置错误或连接池未复用凭证会导致每次新建socket都重认证，延迟叠加、超时频发。
认证超时不是网络慢，而是每次连接都在重复走一遍 auth handshake 流程——尤其当 authSource 配置不当或连接池未复用凭证时，MongoDB 会为每个新 socket 重新校验用户，导致延迟叠加、超时频发。
authSource 写错位置，连接池越建越多
很多开发者把 authSource 当成“可选参数”，只在测试时加，上线后删掉；或者错误地把它塞进 admin 数据库的连接路径里（如 mongodb://u:p@h:27017/admin?authSource=admin），这会让驱动误以为“默认库就是认证源”，从而在连接池扩容时反复尝试用目标库名做 authSource。
- 正确做法：只要用户不在目标库创建，就必须显式指定
authSource，且值必须是用户实际所在的数据库（通常是admin） - 错误示例：
mongodb://appUser:pwd@localhost:27017/reporting→ 驱动默认用reporting查用户，失败后重试，触发连接池新建连接 - 正确示例：
mongodb://appUser:pwd@localhost:27017/reporting?authSource=admin→ 认证上下文固定，连接可复用 - 注意：Node.js 驱动（v4+）、PyMongo（v4.0+）、Go mongo-go-driver 都要求此参数显式存在，否则不缓存 auth 状态
connectTimeoutMS 和 socketTimeoutMS 的真实作用被高估
这两个参数控制的是“建立 TCP 连接”和“单次读写操作”的时限，但对认证耗时无直接缓解。真正卡住连接池的，是 MongoDB 在 SCRAM-SHA-256 握手阶段的多轮往返（尤其是 TLS 启用时），而该过程不受 socketTimeoutMS 约束。
-
connectTimeoutMS只管 TCP 握手完成时间，不包括后续 SASL 认证；若设太小（如1000），反而让合法连接被误杀 -
socketTimeoutMS默认 360000ms（6 分钟），一般无需调低；调高它并不能加速认证，只会拖长失败感知时间 - 真正该调的是
maxIdleTimeMS（空闲连接回收）和minPoolSize（保底连接数），避免频繁重建带 auth 开销的连接 - 推荐组合：
?connectTimeoutMS=30000&maxIdleTimeMS=600000&minPoolSize=5
客户端没启用 auth 缓存，每次 new MongoClient 都重认证
多数驱动（如 PyMongo、Node.js mongodb driver）默认关闭凭证缓存，即每次调用 MongoClient.connect() 或构造新 client 实例，都会新建一套连接池并重新走完整 auth 流程。
- PyMongo：必须传
username/password到MongoClient构造函数，且不能靠环境变量或外部配置绕过；URL 中的凭据不会被跨 client 复用 - Node.js：使用
useUnifiedTopology: true是前提，但还需确保没在每次请求都new MongoClient()；应全局复用单个 client 实例 - Go：
mongo.Connect()返回的*mongo.Client必须复用，重复调用会创建独立连接池，各自认证 - 关键点：认证状态只在单个
Client实例的生命周期内缓存，不跨进程、不跨 client 对象
最容易被忽略的是：MongoDB 的 auth 缓存粒度是「连接池级别」，不是「驱动级别」。哪怕你代码里写了 if (!client) client = new MongoClient(...)，只要部署时多个 worker 进程各自初始化 client，就等于开了 N 套独立认证流程。这时候再怎么调 maxPoolSize，也只是把超时压力从一个池分散到 N 个池而已。
