gridfs默认写入files.md5但不校验，该字段自mongodb 5.0起已弃用；服务端不验证完整性，上传中断或chunk丢失仍可能使md5“匹配”而文件损坏；可靠校验须下载后本地重算哈希或业务层存取checksum。
GridFS默认计算MD5但不校验上传结果
GridFS本身不强制校验MD5，它只是在客户端（如PyMongo、Node.js驱动）上传时默认调用hashlib.md5算一次值，写进files.md5字段。这个字段从MongoDB 5.0起已deprecated，且服务端完全不参与验证——上传过程哪怕网络中断、chunk写入失败、或fs.chunks丢失部分块，只要files集合插入成功，MD5就“看起来一致”，实际文件已损坏。
PyMongo和Node.js驱动的MD5行为差异
不同驱动对disable_md5支持程度不同，容易误以为关掉了却仍在算：
- PyMongo 3.12+：必须在初始化
GridFSBucket时传disable_md5=True，上传时加options={'disable_md5': True}无效 - Node.js driver 4.13+：支持
new GridFSBucket(db, { disableMD5: true }) - Node.js driver 4.12及更早：无该选项，
md5字段必然计算，只能手动写fs.chunks和fs.files绕过
MD5不一致的常见真实原因
不是哈希算法出错，而是底层数据状态不匹配：
-
files.md5是上传时一次性计算的快照，后续修改fs.chunks（如手动清理坏块、修复分片）不会更新该字段 - 使用
mongofiles工具上传时，它自带独立MD5逻辑，与驱动行为不兼容，混用会导致files.md5和实际内容脱钩 - 副本集同步延迟或写关注（
w:1）不足时，部分chunks未落盘就被读取，downloadToStream拼出来的字节流与原始MD5不符 - 调用
filemd5命令校验时，该命令已弃用，且只查files.md5字段，不重新哈希chunks数据
真正可靠的校验方式是什么
别依赖files.md5，它既不安全也不实时。需要一致性保障时，应：
- 下载后本地重算MD5/SHA256，用
openssl dgst -sha256或certutil -hashfile等可信工具 - 若需服务端校验，改用应用层逻辑：上传时由业务生成并存入
files.metadata.checksum，下载后比对 - 对关键文件启用
writeConcern: { w: "majority" }，确保所有副本都写入完整chunk再返回成功
MD5字段只是历史遗留痕迹，它的存在本身就会误导人以为有校验——关掉它，用明确可控的方式做完整性验证，才是实际可行的路径。
