filemd5字段是gridfs唯一内置哈希字段，仅写入时计算一次，用于比对原始文件md5以发现写入错误，但无法检测读取阶段的chunk丢失、解析失败等内容损坏。
filemd5 字段是 GridFS 唯一内置的哈希字段，但它只在写入时计算一次，不是实时校验机制。比对它能发现写入阶段是否出错，但无法覆盖读取后内容损坏、chunk 丢失或解析失败等场景。
上传前必须本地算 MD5 并与 files.md5 比对
驱动（如 PyMongo、Java Driver）在调用标准 GridFS API 上传时，会自动计算原始文件的 MD5 并写入 fs.files.md5 字段。这个值可信的前提是：你用的是标准上传路径，且上传过程未中断。
- Linux/macOS 下用
md5sum 文件名或openssl md5 文件名获取本地 MD5 - 上传后立即查
db.fs.files.findOne({filename: "xxx"})，比对md5字段是否一致 - 若
md5字段为null或缺失，说明没走 GridFS 标准写入流程（比如直插fs.chunks），此时不能依赖该字段做验证
下载后二次校验：用内存数据重算 MD5，再比对 files.md5
很多用户只比对上传前的 MD5，却忽略下载环节可能出问题——比如 chunk 缺失导致 read() 返回字节数不足，但驱动不报错，只是静默拼接不全的数据。
- 下载时务必用
fs.get(file_id).read()一次性读全（注意内存压力），不要分段流式读取后自行拼接 - 拿到
bytes后，用hashlib.md5(data).hexdigest()（Python）或等效方式重算 MD5 - 必须和
fs.files.md5字段值比对，而不是和原始本地文件比——因为原始文件可能已被修改 - 如果两次 MD5 不一致，说明文件在 MongoDB 中已不可逆损坏，
filemd5本身没变，但内容已不对
为什么 filemd5 匹配 ≠ 文件可用
filemd5 是写入快照，它只反映“当时传进去的是什么”，不保证后续 chunk 能被正确读出或解析。常见陷阱包括：
-
fs.chunks中某个n: 5的块丢失，驱动跳过并继续拼接，最终文件变短，但files.length和files.md5都没变 - chunk 的
data字段 BSON 解析失败（如被截断），驱动可能返回空或乱码，但不抛异常，MD5 校验仍通过 - 文件被解压/渲染时报错（如 PNG magic bytes 不对、JSON parse error），但
filemd5完全匹配——这说明损坏发生在存储层之下，比如磁盘位翻转或 WiredTiger 页面损坏
真正可靠的验证不是单点比对 md5，而是把“写入快照”“块连续性”“字节长度”“内容可解析性”四者串起来看。最容易被忽略的是：即使所有检查都通过，只要没在目标环境里实际打开/解压/播放一次，就不能认定文件完整可用。
