GridFS不支持多文件打包下载和Zip压缩，必须在应用层用流式方式组合多个open_download_stream并喂给ZIP库；直接操作fs.chunks集合会丢失元数据、破坏chunk边界、引发并发问题。
GridFS 本身不支持多文件打包下载，更不提供 Zip 压缩能力；必须在应用层用流式方式组合多个 open_download_stream 并喂给 ZIP 库（如 Node.js 的 archiver、Python 的 zipfile.ZipFile with BytesIO）。
为什么不能直接从 GridFS chunks 集合拼 zip？
手动查 fs.chunks 会绕过文件元数据（filename、uploadDate、md5），导致：
- 无法还原原始文件名，所有文件在 zip 中变成无意义的 ObjectId 或数字编号
- 丢失 MIME 类型、自定义 metadata 字段，前端无法正确识别内容类型
- chunk 边界错位时解压失败（比如某 chunk 被截断或重复读取），而
open_download_stream内部做了校验和重试 - 并发读多个文件时，若共享同一 socket 连接但未控制流控，容易触发 MongoDB 的
maxPoolSize耗尽或readConcern不一致
Node.js 实现流式多文件 zip 下载的关键点
以官方驱动 mongodb@6.13 + archiver@7.x 为例，核心是「每个文件走独立 stream，全部 pipe 到 archiver」：
- 用
bucket.find({ filename: { $in: [...] } })批量查files元数据，避免 N+1 查询 - 对每个匹配文档，调用
bucket.open_download_stream(file._id)—— 必须传_id，不用filename，防止 URL 编码/空格/斜杠引发歧义 - 每个 stream 创建后立即
archive.append(stream, { name: file.filename })，不要await流结束，否则串行化失去流式意义 - 设置
res.setHeader('Content-Type', 'application/zip')和'Content-Disposition'，且务必禁用 Express 的res.send()自动处理（它会尝试 JSON 化） - 监听
archive.on('error')并显式res.destroy()，否则客户端可能卡在 pending 状态
Python（PyMongo）中易踩的内存坑
常见错误是把整个文件读进内存再塞进 ZipFile.writestr()：
-
bucket.open_download_stream(...).read()会加载全部 chunk 到 RAM，100MB 文件 = 至少 100MB 内存峰值 - 正确做法是用
io.BytesIO构造可写缓冲区，配合zipfile.ZipFile的writestr()只接收 bytes，或更优：用zipfile.ZipFile的write()方法配合临时命名管道（不推荐）或分块write()+seek() - 真正轻量的方式是使用
stream-zip库（支持 async / streaming write），它允许你传入一个 generator，每次 yield 一个(filename, content_stream)对，content_stream 就是bucket.open_download_stream(...)返回的可迭代对象 - 注意 PyMongo 的
open_download_stream返回的是GridOutChunkIterator，需包装成io.RawIOBase子类才能被stream-zip消费，否则报AttributeError: read
真正难的不是 zip 逻辑，而是让多个 GridFS stream 在高并发下不抢光连接池、不因某个文件损坏拖垮整包——这些边界得靠 timeout、max_concurrency 和提前 abort 控制，而不是指望驱动自动兜底。
