mongo-express默认连接池大小为4，中高并发下易耗尽；应按场景配置minpoolsize与maxpoolsize，如{minpoolsize: 4, maxpoolsize: 12}，并显式声明connectionoptions，避免冷启动开销与连接堆积。
mongo-express 默认连接池大小为 4，但直接沿用这个值在中高并发场景下极易导致连接耗尽、请求卡顿甚至超时失败。关键不是“能不能连上”，而是“能否稳定撑住业务流量”。
连接池大小设置：别硬套默认值，看实际负载
连接池过小（如 poolSize: 2）会导致并发请求排队等待，尤其在批量导入、报表查询或多个集合联查时明显卡顿；过大（如 poolSize: 20）则可能压垮 MongoDB 服务端资源，触发连接拒绝或内存溢出。
- 本地开发/单机测试：设为
2–4足够 - 中等业务量（QPS 50–150）：建议从
6–10开始压测，观察mongostat中的conn和netIn指标 - 生产环境集群：必须结合
maxPoolSize与minPoolSize配合使用，例如{ minPoolSize: 4, maxPoolSize: 12 }，避免冷启动时连接重建开销 - 务必在
connectionOptions中显式声明，不要只改poolSize（旧配置方式已不推荐）
重连逻辑失效的常见原因
很多人以为设置了 autoReconnect: true 就万事大吉，但 mongo-express 实际依赖底层 mongodb 驱动的重试机制，而该机制对连接中断类型有明确区分：
-
serverSelectionTimeoutMS控制“选不到可用节点”的等待上限，默认 30s —— 若副本集主节点切换慢，这个值太小会直接报ServerSelectionError -
connectTimeoutMS是建立 TCP 连接的超时，设太短（如 1000ms）会让网络抖动被误判为宕机 -
socketTimeoutMS影响空闲连接回收，设太长（如 3600000）会导致僵尸连接堆积，影响池内健康连接比例 - 真正有效的重连保障是组合配置：
{ connectTimeoutMS: 5000, socketTimeoutMS: 30000, serverSelectionTimeoutMS: 60000, retryWrites: true, retryReads: true }
Express 中间件集成时的连接生命周期陷阱
把 mongo-express 当作 Express 中间件挂载时，mongoExpressMiddleware() 返回的是一个已初始化的 Router 实例，其内部 MongoDB 连接在模块加载时就建立完毕 —— 这意味着它**不会随 Express 应用重启自动重连**，也不会响应环境变量变更。
- 若你用
process.env.MONGODB_URI动态传入连接串，必须确保在调用mongoExpressMiddleware()前该变量已存在，否则会 fallback 到默认mongodb://localhost:27017 - 连接异常后，当前中间件实例不会自动恢复，需配合进程管理器（如 pm2）监听
uncaughtException并触发整个服务重启 - 更稳妥的做法是：在 Express 的
app.listen()后手动检查连接状态，例如调用db.admin().ping()，失败则process.exit(1)，让容器或 PM2 拉起新实例
连接池和重连不是配完就一劳永逸的事，特别是当你的 Express 应用启用了 cluster 模式或多实例部署时，每个 worker 进程都会持有一组独立连接池 —— 这时候总连接数 = worker 数 × poolSize，很容易超出 MongoDB 的 maxConnections 限制，这点常被忽略。
