Node.js MongoDB连接池溢出主因是maxPoolSize默认100过高且缺minPoolSize与maxIdleTimeMS：cluster多worker叠加致连接数飙升，空闲连接永不释放；应按QPS×p95延迟/1000公式设maxPoolSize，并配minPoolSize保底、maxIdleTimeMS强制淘汰。
Node.js 的 MongoDB 连接池溢出，90% 是因为 maxPoolSize 设得太大，且没配 minPoolSize 和 maxIdleTimeMS，导致连接堆积不释放。
为什么 maxPoolSize 默认值在生产环境很危险
Node.js 官方驱动（v4.0+）默认 maxPoolSize: 100，但这个“100”是每个 MongoClient 实例的上限。如果服务用 cluster 模式起了 4 个 worker、又没做单例管理，实际连接数就可能飙到 400；再加上负载均衡后多个实例，mongos 很快被压满。
更关键的是：这个值只管“上限”，不管“下限”和“存活时间”。连接建了就挂着，哪怕 10 分钟没请求，也继续占着 socket 和内存。
-
minPoolSize不设（默认 0），空闲时连接会逐步归零 —— 但归零过程慢，且高并发突增时又要重建，反而加重延迟 -
maxIdleTimeMS不设（默认 0），空闲连接永不释放，netstat -an | grep :27017 | wc -l看到的 ESTABLISHED 数只会涨不会跌 - 若同时用了
useUnifiedTopology: true（必须开），但没配serverSelectionTimeoutMS，连接失败时还会卡住线程等超时，进一步拖慢回收
maxPoolSize 应该设多少才合理
不是拍脑袋定数字，而是看真实 QPS 和平均响应时间。一个经验公式：maxPoolSize ≈ (QPS × p95_latency_ms) / 1000。比如 QPS=200、p95=150ms，理论需约 30 个连接 —— 此时设 maxPoolSize: 40 就够用，再加 minPoolSize: 5 防冷启抖动。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 中小业务（QPS maxPoolSize: 10~20，
minPoolSize: 2，maxIdleTimeMS: 60000 - 高吞吐聚合场景（大量
$lookup或跨分片查询）：可放宽到maxPoolSize: 30，但必须同步加socketTimeoutMS: 30000防长连接挂死 - 绝对不要设成 100 或更高 —— 除非你已确认 mongos 和 mongod 的
maxIncomingConnections足够，并监控过db.serverStatus().connections持续低于 80%
连接池泄漏的典型现象与验证方式
光调参数不够，得能一眼识别是不是真泄漏。最直接的方法是：在服务稳定运行 10 分钟后，执行 db.currentOp({ "secs_running": { "$gt": 0 } })，看有没有大量状态为 "awaitingTopologyChanges" 或 "connecting" 的操作 —— 这说明连接卡在初始化阶段，大概率是 DNS 解析慢、mongos 地址写错、或 TLS 握手失败。
- 用
lsof -i :27017 | wc -l对比应用进程 PID 的连接数，和mongostat --host mongos-host:27017 | head -20显示的conn值。两者长期不一致，基本就是客户端没关干净 - 在
MongoClient初始化后加日志：client.on("connectionPoolCreated", e => console.log("pool created:", e))和client.on("connectionPoolClosed", e => console.log("pool closed"))，观察是否只创建不关闭 - 注意
poolSize（mongoose 旧参数）和maxPoolSize（原生驱动）别混用 —— mongoose v6+ 已弃用poolSize，设了也不生效
真正起效的最小配置组合
以下配置经压测验证，在 QPS 300、平均延迟 80ms 场景下，连接数稳定在 25±3，无泄漏：
const client = new MongoClient(uri, {
maxPoolSize: 30,
minPoolSize: 5,
maxIdleTimeMS: 60000,
socketTimeoutMS: 45000,
serverSelectionTimeoutMS: 5000,
connectTimeoutMS: 10000
});
重点不是数字本身，而是这组参数形成了闭环：有上限、有保底、有淘汰机制、有失败兜底。漏掉任意一项，都可能让连接在某个环节卡住不动 —— 尤其是 maxIdleTimeMS，它不像 maxPoolSize 那样显眼，但却是防止连接静默堆积的最后一道阀。
