v6.0连接池调度更激进，waitQueueTimeoutMS默认无限等待易致请求卡死，需显式设为3000~5000ms；minPoolSize在v6.0+才真正保底生效；协议不匹配（如旧驱动连v6.0）会导致连接频繁断连重连，使连接池参数失效。
maxPoolSize 在 v4.x 与 v6.0 中的行为差异
默认值没变（仍是 100），但 v6.0 对连接池的调度更激进：当并发请求持续超过 maxPoolSize 时，v4.x 容易堆积等待队列，而 v6.0 更快触发 waitQueueTimeoutMS 超时并抛出 MongoServerSelectionError。这不是 bug，是连接复用策略收紧的结果。
实操建议：
- 升级到 v6.0 后，若应用偶发
MongoServerSelectionError: Server selection timed out，先检查是否maxPoolSize设置过小，而非直接调大——应先确认真实并发量是否合理 - v6.0 中监控连接使用率更关键：
db.currentOp({ "secs_running": { "$gt": 0 } })配合驱动日志里的poolStats输出，比单纯调高maxPoolSize更治本 - 若用的是 Node.js 驱动，
minPoolSize在 v6.0+ 才真正“保底”生效；v4.x 即使设了minPoolSize: 5，空闲时仍可能缩到 0
waitQueueTimeoutMS 和 maxIdleTimeMS 的兼容性陷阱
v4.x 默认 waitQueueTimeoutMS=0（无限等待），v6.0 推荐显式设为 5000（5 秒）；但很多老项目沿用默认值，上线后在流量高峰出现请求卡死数分钟，日志里却只看到模糊的 ServerSelectionTimeoutError。
常见错误现象：
- 本地开发一切正常，压测或上线后部分请求延迟突增至 30s+，且无明确错误堆栈
- 连接池监控显示
inUseCount长期接近maxPoolSize，但availableCount不为 0 —— 说明连接没被释放，而是卡在等待队列
实操建议：
- 必须显式配置
waitQueueTimeoutMS，不要依赖默认值；v6.0 下建议设为3000~5000，配合业务超时时间 -
maxIdleTimeMS在 v4.x 基本无效（驱动未严格执行），v6.0 起才真正强制回收空闲连接；若部署在有 NAT 网关或防火墙的环境，务必设为小于网关超时值（如30000）
驱动协议变更导致连接池“假满”
v6.0 强制禁用 op_insert 等旧协议，改用 op_msg。如果驱动版本没同步升级（比如还在用 mongodb@3.7 连 v6.0 服务端），连接池会频繁断连重连，表现为 poolStats 中 createdCount 持续上涨、reclaimedCount 高，但 availableCount 波动剧烈。
这不是连接池配置问题，而是协议不匹配引发的连接生命周期紊乱。
实操建议：
- 检查驱动版本与 MongoDB 服务端版本的兼容矩阵，
mongodb@4.17+是安全连 v6.0 的最低要求 - 在连接字符串中加
?appName=myapp，再查db.currentOp()，能快速识别哪些连接来自过时驱动 - 不要试图用
minPoolSize补偿断连——只会加剧资源争抢
Laravel + MongoDB v6.0 下的 connection 复用误区
Laravel 的 mongodb 包（v4.x）默认为每次请求新建 MongoClient 实例，即使 DSN 相同。这导致连接池被隔离在每个请求生命周期内，maxPoolSize 实际作用范围被严重压缩。
结果就是：明明设了 maxPoolSize: 100，但单个请求最多只能用到 1~2 个连接，其余全闲置。
实操建议：
- 在 Laravel 中必须手动复用
MongoClient实例，例如通过app('mongodb')绑定为 singleton - 避免在模型中重复调用
new \MongoDB\Client()；Eloquent 模型应共享同一个 client - 检查
config/database.php中的options是否透传了连接池参数——Laravel v4.x 的 mongodb 包对options支持不完整，需升级包或打 patch
