maxPoolSize设200–400更稳妥；盲目增大易触服务端限制，真正耗尽主因是流未关闭或元数据写入串行，而非池大小不足。
maxPoolSize设多大才算够用？别盲目堆数字
连接池耗尽不是因为池子太小，而是连接被长时间占用没释放。把 maxPoolSize 从默认 100 直接拉到 500，反而可能触发 MongoDB 服务端的 net.maxIncomingConnections 限制，引发服务端拒绝新连接。实测在千兆内网、WiredTiger 引擎下，200–400 是更稳妥的区间；超过 400 必须同步检查服务端配置，并监控 serverStatus.connections.current 是否逼近上限。
-
minPoolSize别设为 0：冷启动时并发突增，所有线程卡在建连阶段，表现就是首请求延迟飙高 -
maxConnectionLifeTime设 30–60 分钟：强制回收老化连接，防止因网络抖动导致的连接泄漏累积 -
maxConnectionIdleTime建议 5–10 分钟（比默认 30 分钟更激进）：空闲连接不及时归还，新请求就得排队等
GridFS 流不关，连接就永远不还池
绝大多数连接池耗尽，根源不在配置，而在流对象没正确销毁。每个 openUploadStream 或 openDownloadStream 都会从池里取一个连接，而这个连接直到流彻底关闭才会释放。
- Node.js 中必须显式调用
stream.destroy()或监听'close'后再结束响应；仅靠res.end()不够 - Java 里不能只依赖 try-with-resources：若
GridFSDownloadStream.read()抛异常提前退出，AutoCloseable可能未触发，得手动try/finally调用close() - Python 的
stream.close()虽有 GC 保底，但显式关闭能更快释放 socket 和 chunk cursor，尤其在 FastAPI 等异步框架中
为什么加了索引还是慢？fs.chunks 缺复合索引
并发下载卡顿，90% 情况下不是连接池问题，而是 fs.chunks 查询没走索引。GridFS 下载时内部按 files_id 和 n 查块，如果只有单字段索引，MongoDB 就得内存排序或全表扫描。
- 必须建
{"files_id": 1, "n": 1}复合索引，且顺序不能反——files_id在前才能快速定位文件，n在后才能支持顺序读取 - 别加
data字段进去：索引体积爆炸，且不参与查询条件 - 验证是否生效：用
db.fs.chunks.explain("executionStats").find({ files_id: ObjectId("..."), n: { $gte: 0 } })，看executionStages.stage是不是IXSCAN
上传吞吐卡在 20–30 QPS？元数据写入成了串行点
GridFS 写入瓶颈往往不在 fs.chunks，而在 fs.files 的首次插入。所有并发上传默认都通过同一个 GridFSBucket 实例调用 openUploadStream，而它内部会同步执行 fs.files.insertOne()，形成隐式锁竞争。
- 不要复用单个
GridFSBucket实例做高并发上传；可按业务分桶，比如"uploads_2024q3"，天然隔离元数据写入竞争 - 预分配
ObjectId并用openUploadStreamWithId()跳过fs.files自动插入，彻底绕开元数据写入阻塞 -
chunkSizeBytes设 256KB 是千兆内网下的实测平衡点；太小（如 16KB）导致插入频次过高，太大（如 4MB）拖慢单流响应
真正容易被忽略的，是流生命周期和元数据写入这两个非配置类问题。参数调得再细，流不关、fs.files 插入不拆分，连接池照样满。
