gridfs读取大文件内存暴涨的根本原因是流控失效、缓冲区堆积和索引页挤占缓存三者叠加：node.js驱动默认逐chunk反序列化并拷贝buffer，未用.pipe直连导致v8堆内存积压；fs.chunks复合索引占用大量wiredtiger缓存；并发读取触发页面频繁淘汰重载。
GridFS 读取大文件时内存暴涨，根本不是“数据太大”，而是流没控住、缓冲区堆满、索引页挤占缓存这三件事同时发生——尤其在 Node.js 环境下，V8 堆内存比 WiredTiger 缓存更早崩。
Node.js 驱动默认把整个 chunk 读进 Buffer 再转发
openDownloadStream() 返回的 Readable 流，默认行为是：每收到一个 BSON chunk 文档，驱动先完整反序列化它，再把 data 字段拷贝进一个新的 Buffer，最后 emit 出去。对 100MB 文件（默认 255KB 分块 ≈ 400 个 chunk），等于要创建 400 次中间 Buffer，且 V8 堆里同时存在多个未被 GC 的副本。
- 别用
.on("data", buf => ...)手动拼接，这是最典型的内存陷阱；改用.pipe(dest)直连目标流（如fs.createWriteStream()或 HTTPres） - 确保目标流有背压控制：比如 Express 中用
res.write()时设highWaterMark: 64 * 1024，否则数据会在内存中堆积 - 禁用任何 transform stream（如
JSON.stringify、zlib.createGunzip()）中间层，除非你明确设了highWaterMark并监听drain
fs.chunks.files_id 索引吃掉大量 WiredTiger 缓存
这个索引不是“可选配件”，而是 GridFS 查询路径的必经之路：每次 openDownloadStream() 都要按 files_id 扫 fs.chunks。百亿级小文件场景下，该索引本身就能占满几十 GB 缓存，把真正要读的 chunk 数据页全挤出去。
- 执行
db.fs.chunks.getIndexes()看是否建了{ files_id: 1, n: 1 }复合索引；如果业务从不手动查 chunks，可直接删：db.fs.chunks.dropIndex({ files_id: 1, n: 1 }) - 检查
db.serverStatus().wiredTiger.cache["bytes currently in the cache"]占比，若超 90% 且"tracked dirty bytes"很低，说明缓存被索引页长期霸占 - 别指望靠
cacheSizeGB硬扛——索引体积是数据的 1.2–1.8 倍，调大只会让 OS 缓存更缺页
并发读取触发 WiredTiger 页面老化策略失效
多个大文件并发读取时，WiredTiger 会快速淘汰“刚写入就没人读”的 chunk 页面，但 GridFS 下载流又不断触发新页面加载，形成“加载→淘汰→重加载”死循环，CPU 和 I/O 都在空转。
- 监控
"pages evicted by age"是否远高于"pages evicted by the application"；高则说明 chunk 数据还没被下游消费完就被踢出缓存 - 对批量下载任务，限制并发数（如用
p-limit控制最多 3–5 个流同时跑），比调大缓存更有效 - 如果必须高并发，考虑把
fs.chunks设为noPadding: true并定期compact，减少碎片提升缓存利用率
真正卡住你的往往不是单次读取，而是“流没关、索引没删、并发没限”这三件事叠在一起——它们不会报错，但会让内存曲线一路拉到 OOM 边缘，而且日志里几乎找不到直接线索。
