必须绕过GridFS自动分块，改用openUploadStreamWithId()+手动分块+块级加密，分块大小与chunkSizeBytes严格对齐（如1024×1024），AES-GCM需将authTag追加至每块密文尾，metadata中仅存key_id和base64编码的iv，解密时按相同块大小提取末16字节authTag。
不能直接 pipe 加密流给 openUploadStream
GridFS 本身不加密，也不能靠 fs.createReadStream().pipe(cipher).pipe(bucket.openUploadStream()) 实现——这会导致解密失败。根本原因是：AES-CBC 需填充、AES-GCM 生成 authTag，而 GridFS 的 chunk 切分（默认 chunkSizeBytes: 255 * 1024）是固定的，加密后长度变化会破坏 chunk 对齐。下游 downloadStream 按原尺寸读块，拿到的就不是完整密文块，IV 或 tag 必然错位。
常见错误现象包括：Error: Unsupported state or unable to authenticate data（GCM）、Invalid padding（CBC），或下载内容乱码/截断。
- 必须绕过自动分块，改用
openUploadStreamWithId()+ 手动分块 + 块级加密 - 分块大小必须显式设为和
chunkSizeBytes一致（如1024 * 1024），且推荐用 AES-CTR（长度不变）或 AES-GCM（需把authTag追加到每块密文尾） - 每块明文调用
cipher.update(chunk)+cipher.final()，再拼上cipher.getAuthTag()后写入 -
metadata中存{ encryption: "aes-256-gcm", iv: iv.toString('base64'), key_id: "k2026" }，iv必须每文件唯一
Node.js 中块级 AES-GCM 加密上传实操
核心是控制加密边界与 chunk 边界严格对齐。不要复用 crypto.createCipheriv 实例，每个块都需新初始化（但共用同一 key 和 iv）。
示例关键片段：
const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);
cipher.setAAD(Buffer.from('')); // 可选 AAD
const encryptedChunk = Buffer.concat([
cipher.update(chunk),
cipher.final()
]);
const authTag = cipher.getAuthTag();
const encryptedChunkWithTag = Buffer.concat([encryptedChunk, authTag]); // 总长 = 密文 + 16
uploadStream.write(encryptedChunkWithTag);- 调用
bucket.openUploadStreamWithId(fileId, { chunkSizeBytes: 1024 * 1024 })，确保驱动不重分块 - 读取源文件时用
fs.createReadStream(path, { highWaterMark: 1024 * 1024 })控制每次data事件的 chunk 大小 - 别在
metadata存原始key，只存key_id，密钥由 KMS 或环境变量注入 - 解密时必须按相同块大小读 chunk，提取最后 16 字节为
authTag，再用剩余部分初始化decipher
Python（PyMongo + pycryptodome）上传要点
PyMongo 不支持流式块级加密上传，必须手动分块读取 + 加密 + 写入。不能用 gridfs.GridFS(db).put()，它把整个 bytes 当作明文塞进去，没机会插加密逻辑。
- 用
os.urandom(32)生成 key，Random.new().read(AES.block_size)生成 iv（别硬编码） - 分块读：用
with open(path, 'rb') as f:+f.read(1024*1024)，每块调AES.new(key, AES.MODE_GCM, iv) - 每块获取
ciphertext和tag，拼成ciphertext + tag写入 - 上传时用
bucket.open_upload_stream_with_id()，并显式传chunk_size_bytes=1024*1024 - metadata 存
{"encryption": "aes-256-gcm", "iv": base64.b64encode(iv).decode(), "key_id": "k2026"}
别漏掉传输层和存储层的加密分工
TLS 和 WiredTiger 加密不是替代应用层 AES 的方案，而是互补角色。漏掉任一环，敏感文件都可能裸奔。
- 传输加密靠驱动配置：
tls=True+tlsCAFile（自签名证书必填），URI 里写mongodb+srv://不等于自动安全，得确认握手成功 - 磁盘静态加密（WiredTiger
enableEncryption）只防物理窃盘，对勒索病毒删fs.files集合完全无效 - 应用层 AES 加密是唯一能防止数据库管理员或被入侵账号直接读取文件内容的手段
- 三者缺一不可：TLS 防中间人、WiredTiger 防硬盘被盗、AES 防权限内泄
最易被忽略的是块边界与加密边界对齐——哪怕算法、密钥、IV 全对，只要 chunkSizeBytes 和实际加密块长不一致，解密就必然失败。这不是调试问题，是设计前提。
