gridfs本身不支持aes加密，必须在应用层流式加解密：写入前加密、读取后解密，且需将iv和认证标签与密文一并存储；python用cryptography.hazmat流式处理，node.js用crypto.createcipheriv配合pipeline。
GridFS本身不支持AES加密，必须在应用层做流式加解密
GridFS只是把文件切块存进 fs.files 和 fs.chunks 两个集合，它不干预内容字节——这意味着你传进去什么，它就原样存什么。想对PDF做AES加密，不能靠MongoDB配置或GridFS选项，得在写入前加密、读取后解密。关键在于：**必须用流式（streaming）方式处理，否则大文件会爆内存**。
常见错误是先生成完整PDF，再用 AES.encrypt() 包整个 Buffer，这会让100MB的报表在内存里存两份（原始+加密后），GC压力陡增。正确路径是让加密器接在PDF生成流和GridFS上传流之间，形成“PDF生成 → AES加密 → GridFS写入”管道。
Python中用cryptography库串联BytesIO + AESGCM + GridFS.put()
用 cryptography.hazmat.primitives.ciphers 做AEAD加密（推荐AESGCM），避免手动管理IV和认证标签。注意三点：
-
GridFS.put()接收类文件对象（file-like object），所以要把加密后的字节喂给它，而不是传原始PDF流 - IV必须随文件一起保存，但不能硬编码；标准做法是把12字节IV放在加密数据最前面（或存在
metadata里），解密时先读出再切分 - 必须在加密前调用
pdf_buffer.seek(0)，否则GridFS.put()从末尾开始读，得到空内容
示例片段：
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives import padding
from io import BytesIO
<h1>假设 pdf_buffer 是 reportlab 生成的 BytesIO 流，已 seek(0)</h1><p>key = b'32_byte_secret_key_for_aes_256'
iv = os.urandom(12) # GCM 标准 IV 长度
encryptor = Cipher(algorithms.AES(key), modes.GCM(iv)).encryptor()</p><h1>加密流：先 update，再 finalize_with_tag</h1><p>encrypted_data = encryptor.update(pdf_buffer.read()) + encryptor.finalize_with_tag()</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/ai/2986" title="剧云"><img
src="https://img.php.cn/upload/ai_manual/001/246/273/6a2bc27b840e0676.png" alt="剧云" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/ai/2986" title="剧云" class="overflowclass">剧云</a>
<p class="overflowclass">一款AI工具，主要用于专业、高效、安全的中文剧本在线创作与管理工具，适合需要提升相关任务效率的用户。</p>
</div>
<a rel="nofollow" href="/ai/2986" title="剧云" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><h1>合并 IV + tag + 密文，作为新流传给 GridFS</h1><p>full_encrypted = iv + encryptor.tag + encrypted_data
encrypted_stream = BytesIO(full_encrypted)
encrypted_stream.seek(0)</p><p>gfs.put(encrypted_stream, filename="report.pdf", content_type="application/pdf", metadata={
"encrypted": True,
"cipher": "AES-GCM-256",
"iv_length": 12,
"tag_length": 16
})</p>
Node.js里用crypto.createCipheriv()配合GridFSBucket.openUploadStream()
Node.js 的 crypto 模块原生支持流式加密，比Python更自然。但要注意：openUploadStream() 返回的是 Writable 流，不能直接 pipe() 给它，因为加密流是 Readable，而上传流需要你主动 write() 或 end()。
实操建议用 pipeline（Node 15.9+）或手动 on('data') 转发：
- 别用
createCipher()（已弃用），必须用createCipheriv(algorithm, key, iv) - GCM模式下，
setAuthTag()只能在final()后调用，所以必须等整个PDF Buffer加密完才能拿到tag——这意味着对超大PDF，仍需分块加密（见下条） - 若PDF由
puppeteer流式生成（如边渲染边写），应改用Transform流串联：PDF readable → AES transform → uploadStream
小文件可简化处理：
const { createCipheriv, randomBytes } = require('crypto');
const iv = randomBytes(12);
const cipher = createCipheriv('aes-256-gcm', key, iv);
<p>const encrypted = Buffer.concat([
iv,
cipher.update(pdfBuffer),
cipher.final(),
cipher.getAuthTag()
]);</p><p>const uploadStream = bucket.openUploadStream('report.pdf', {
contentType: 'application/pdf',
metadata: { encrypted: true }
});
uploadStream.end(encrypted); // 注意是 end(), 不是 write()</p>
解密时最容易忽略的三件事
加密只是半程，解密出错会导致PDF打不开，且错误现象隐蔽（比如只显示空白页或报“损坏的PDF”）：
- IV和tag必须严格按写入顺序切分：前12字节是IV，后16字节是tag，中间全是密文；少一个字节就会解密失败
- 解密用的key必须和加密完全一致，Node.js里
Buffer.from(keyString)和keyString直接传入行为不同，容易因编码差异导致key错位 - GridFS下载返回的是加密后的完整流，你得先用
read()拿到全部Buffer，再解密，**不能边读边解密后直接吐给HTTP响应流**——因为GCM要求完整密文+完整tag才能验证通过，中途断掉就失败
真正难的不是加解密逻辑，而是把加密粒度和GridFS chunkSize对齐。默认chunkSize=255KB，而AES块是16B，GCM tag固定16B——只要不手动分块，这个对齐问题其实不存在。但一旦你为性能调大chunkSize（比如设成1MB），又希望支持断点续传或范围下载，就必须自己实现分块加密/解密协议，这时就超出GridFS能力范围了。
