filemd5字段用于比对原始文件哈希值，由驱动写入时自动计算并存入files集合，是GridFS唯一内置哈希字段；上传前应本地计算MD5并与之比对。
用 filemd5 字段比对原始文件哈希值
GridFS 本身不校验文件内容完整性，filemd5 是唯一内置的哈希字段，由驱动在写入时自动计算并存入 files 集合。它不是实时校验机制，而是“写入快照”——只要写入过程没出错，这个值就是可信的起点。
实操建议：
- 上传前先用本地工具（如
md5sum或openssl md5）算出原始文件的 MD5，和 GridFS 中files.filemd5字段比对 - 注意：不同语言驱动对
filemd5的生成逻辑一致，但部分旧版 PyMongo（null - 如果
filemd5字段缺失，说明文件写入未走标准 GridFS API，不能依赖此方式判断
读取时触发 read() 异常或字节数不匹配
损坏常在读取阶段暴露：数据块（chunks）丢失、_id 错位、或 BSON 解析失败。这不是“校验失败”，而是 I/O 层直接报错。
常见错误现象：
-
GridFSBucketDownloadError（PyMongo）、GridFSFileNotFound（Java）——对应 chunk 缺失或files._id在chunks.files_id中找不到匹配 - 读取返回字节数
len(data) != files.length——说明 chunk 拼接不全，可能是部分 chunk 被误删或写入中断 - 解压/解析失败（如 PNG 头损坏、JSON 格式错误）——此时
filemd5可能仍匹配，但内容已不可用
手动验证 chunk 完整性（绕过驱动缓存）
驱动默认拼接 chunk 并缓存结果，掩盖底层碎片问题。真要排查，得绕开封装，直查 chunks 集合。
实操建议：
- 查
chunks.files_id是否全部指向存在的files._id：db.chunks.find({ files_id: { $not: { $in: db.files.distinct("_id") } } }) - 检查每个文件的 chunk 数量是否等于
Math.ceil(files.length / files.chunkSize)（注意chunkSize默认 255KB，可被覆盖） - 逐个读 chunk 的
data字段，用BSON.decode尝试解析——若某 chunk 的data字段是截断或乱码 BSON，说明该 chunk 存储异常
为什么不能只靠 db.fs.files.count() 和 db.fs.chunks.count() 做一致性判断
数量对得上，不代表文件可用。两个集合数量匹配只是最粗粒度的“结构完整”，掩盖了大量隐性损坏。
典型陷阱：
- 同一个
files._id被多个 chunk 引用（重复插入），导致读取时数据重复拼接 - chunk 的
n字段不连续（如缺了n: 5），驱动会静默跳过，最终文件变短 -
files.length被人为修改过，但 chunk 实际内容没变——哈希和长度都对不上真实状态
真正关键的不是“有没有”，而是“能不能按序拼出原始比特流”。这点必须落到单文件的读取路径里验证，没法靠聚合统计蒙混过关。
