直接降低gridfs大文件读取内存占用的关键是绕过驱动默认全chunk缓存，改用流式消费：使用opendownloadstreambyname、调大chunksizebytes、显式设置highwatermark、跳过fs.files查询，并确保下游支持背压。
直接降低 GridFS 大文件读取内存占用，核心不是“压缩数据”或“关掉解析”，而是绕过驱动默认的全 chunk 缓存行为，用流式消费代替中间 Buffer 拼接。
Node.js 中 openDownloadStream() 默认会吃光内存
Node.js driver 的 bucket.openDownloadStream() 返回一个 Readable 流，但如果你直接 pipe() 到 fs.createWriteStream() 或 res，看似没问题——实际底层仍会为每个 chunk 分配独立 Buffer，并在内部做 Buffer.concat() 类操作（尤其在 error 处理、pause/resume 逻辑中）。对 500MB 文件，可能瞬时多占 100MB+ 堆内存。
- 避免
stream.on("data", buf => { ... })后手动拼接Buffer—— 这等于自己实现低效 concat - 不要调
stream.read()反复拉小块；改用pipe()但确保下游能背压（如res设置highWaterMark: 64 * 1024） - 显式设置
highWaterMark：创建流时传{ highWaterMark: 32 * 1024 }，限制单次缓存上限
跳过 fs.files 查询可省一次 BSON 解析和内存分配
常见写法是先 files.find({ filename: "xxx" }) 拿到 _id，再 openDownloadStream(file._id)。这多一次 round-trip，且驱动要把整个 fs.files 文档反序列化成 JS 对象（含 uploadDate、length 等字段），哪怕你只想要 _id。
- 改用
bucket.openDownloadStreamByName("xxx")（MongoDB 4.4+），驱动内部用findOne()+find()合并查询，返回流时已知files_id，跳过额外解析 - 如果必须按其他字段查（如
user_id），别手写files.find()，而是建元数据集合，用metadata.findOne({ user_id: "...", file_type: "video" })查出file_id再流式读 - 确认
fs.files.filename有索引：db.fs.files.createIndex({ filename: 1 })，否则openDownloadStreamByName会全表扫
chunkSizeBytes 调大后，流式吐出更“顺滑”
默认 chunkSizeBytes: 255 * 1024（约 255KB），一个 1GB 文件要解析 4000+ 个 BSON chunk 文档。每次解析都触发 V8 堆分配、GC 扫描，叠加流式 write 的 buffer 拷贝，内存毛刺明显。
- 把
chunkSizeBytes改为1024 * 1024（1MB）或4 * 1024 * 1024（4MB），chunk 数量直降，BSON 解析开销减少 4–16 倍 - 注意：改完后旧文件不会自动重分块，需重新 upload；新上传文件才生效
- 别设超过
8 * 1024 * 1024—— WiredTiger 单文档硬限 16MB，chunk 还含元数据字段，超限写入失败报Document too large
真正卡内存的从来不是数据本身，而是驱动层反复的 BSON 解包、Buffer 分配、中间态拼接。调参数只是辅助，关键得让数据从 chunks 集合出来后，不落地、不拷贝、不攒 batch，直接推给下游。这点在 Node.js 的 stream pipeline 里最容易被忽略——因为看起来“已经用了流”。
