GridFS高并发写入连接池被占满的直接原因是每个uploadStream独占连接且未释放；必须限流并发（建议3–5个）、显式调用end()、禁用bodyParser，并按真实负载校准maxPoolSize与waitQueueTimeoutMS。
GridFS高并发写入时连接池被占满的直接原因
不是GridFS本身慢，而是每个上传操作独占一个连接且不释放。Node.js驱动中，uploadStream底层会绑定一个MongoDB连接，若上传中途出错、超时或未调end()，该连接就卡在“in use”状态，永远不归还池子。并发100个上传，最多可能吃掉100个连接——而默认maxPoolSize通常只有10或50。
必须显式控制并发数，不能靠Promise.all塞满
用Promise.all([streams.map(upload)])是高危操作：一个失败就全崩，且所有流同时争抢连接和内存缓冲区。正确做法是限流 + 逐个推进：
- 用
p-limit或async-pool控制并发数，生产环境建议3–5个（机械盘场景下超过5个I/O竞争反而更慢） - 每个上传必须包裹
try/catch，并在finally里确保uploadStream.end()被调用 - 禁用
bodyParser等中间件对multipart的自动解析，否则文件还没进GridFS，内存已先爆
事务混用GridFS时连接泄漏风险加倍
如果上传逻辑包在withTransaction()里，问题更隐蔽：事务内创建的uploadStream仍会绑定到该事务会话，但withTransaction()只保证session自动结束，不保证stream清理。容易踩的坑包括：
- 手动调
startTransaction()后忘了endSession()，连接永久泄漏 - 上传流报错后没
abortTransaction()，会话卡住，连接无法复用 - 事务中嵌套多个GridFS操作，每个都新建stream，连接数线性增长
实操上，GridFS上传尽量避免裹进事务——它本身是原子写入，元数据与chunks写入由驱动保障一致性；真要强一致性，改用uploadId做断点续传，比事务更轻量。
连接池参数必须按真实负载校准，不能拍脑袋设
maxPoolSize不是越大越好。假设你峰值QPS=300，单次上传平均耗时1.2秒，则同时活跃连接数≈360；再乘1.5缓冲系数，maxPoolSize设为540才合理。但要注意：
- 这个值要同步调大mongos或mongod的
maxConns，否则服务端先拒绝连接 -
waitQueueTimeoutMS必须设（推荐3000–5000ms），否则请求无限排队，OOM前先看到大量Timeout waiting for a pooled item - 分片集群下，一个GridFS上传可能跨多个shard，连接消耗是单节点的N倍，得按shard数再放大预估
最容易被忽略的是冷启动抖动：minPoolSize设太低（如0），突发流量进来时，驱动要临时建连，机械硬盘上建连延迟可达200ms以上，直接拖垮首屏体验。
