GridFS通过fs.files和fs.chunks两集合分块存储大文件，支持流式上传下载，避免内存加载，需用标准MIME类型如"application/pdf"并注意seek(0)等细节。
GridFS 本身不支持“直接写入内存流”这种说法——它只接受可读流（ReadableStream）或字节流（bytes / Buffer），但关键在于：**你不需要先落地成文件，只要能构造出字节流或流对象，就能跳过 open() 和磁盘 IO**。
下面分三块讲清怎么做、为什么这么选、以及最容易翻车的地方。
用 io.BytesIO 构造内存 PDF 流（Python）
动态生成 PDF（比如用 reportlab 或 weasyprint）后，别调 .save() 到磁盘，改用 BytesIO 接住二进制内容：
from io import BytesIO- 生成 PDF 后，调用
pdf_buffer = BytesIO(); doc.save(pdf_buffer); pdf_buffer.seek(0) - 此时
pdf_buffer就是可被GridFS.put()直接消费的类文件对象 - 注意必须
seek(0)，否则put()从末尾开始读，得到空内容
gfs.put() 的参数陷阱：别传 content_type 为 "PDF"
常见错误是写 content_type="PDF"，这会导致浏览器无法正确识别 MIME 类型。实际应传标准 MIME 类型：
- PDF 必须用
content_type="application/pdf" - 如果用
mongoengine.FileField，它的put()方法也认这个值，不是随便字符串 - 漏传
content_type时，GridFS不会自动推断，files集合里该字段为空，后续 API 返回头可能缺失Content-Type - 元数据字段如
metadata可额外传字典，比如{"report_id": "20260419-001", "generated_by": "admin"}
Node.js 中用 Buffer 或 Readable 直接上传（无临时文件）
Node 端生成 PDF（如用 puppeteer 或 pdf-lib）后，拿到的是 Buffer，可直接喂给 GridFSBucket.openUploadStream()：
const uploadStream = bucket.openUploadStream(filename, { content_type: "application/pdf" });-
uploadStream.end(pdfBuffer);—— 注意是end()，不是write()，因为Buffer是完整数据 - 若用流式生成（如边渲染边写），才需
pipe()；多数报表场景用Buffer更稳 - 不要用
fs.createWriteStream中转，那又绕回磁盘了
为什么不用 mongoengine.FileField 存动态 PDF？
它底层仍走 GridFS，但封装层有隐藏成本：
- 必须继承
Document，意味着每份 PDF 都要建一个文档实体，不适合高频、无结构元数据的报表场景 -
FileField.put()不支持传chunkSizeBytes，无法控制分块大小，默认 255 KiB，对小 PDF（chunks 文档 - 查询时得先查
Document实例再取.file，比直接gfs.find_one()多一次 round-trip - 真要用它，记得
connect()时显式指定db_alias，否则可能连错库
真正容易被忽略的是：GridFS 的 files 集合里，length 字段是总字节数，chunkSize 是每个块上限，但 **uploadDate 是服务器时间，不是客户端生成时间**。如果你依赖时间戳做清理或排序，得在 metadata 里额外存一个客户端生成的 generated_at。
