可直接查files集合的filemd5字段去重，但仅作初筛；filemd5为null或缺失者不参与判断；重复时需结合读取验证及chunks层检查，删除须用bucket.delete确保关联chunk清理。
直接查 files 集合的 filemd5 字段是否重复
GridFS 的 files 集合中，filemd5 是唯一由驱动在写入时自动计算并存入的哈希字段。它不是实时校验值，但可作为内容一致性的初始快照依据。只要文件是通过标准 GridFS API（如 GridFSBucket.openUploadStream）写入的，该字段就可信。
注意：filemd5 为 null 或缺失，说明该文件未走标准流程上传（比如直插 files 文档），这类记录不能参与去重判断。
聚合查询示例（查找所有重复的 filemd5）：
db.fs.files.aggregate([
{ "$match": { "filemd5": { "$ne": null } } },
{ "$group": { "_id": "$filemd5", "count": { "$sum": 1 }, "ids": { "$push": "$_id" } } },
{ "$match": { "count": { "$gt": 1 } } }
])
返回结果中每个文档代表一个重复的 MD5 值，ids 数组列出所有对应文件的 _id。
为什么不能只依赖 filemd5 判断“内容真正相同”
filemd5 相同，只说明这些文件在写入那一刻的原始字节流哈希一致；但它掩盖了两类关键风险：
- 多个文件共用同一
filemd5，但实际 chunk 数据被篡改或拼接错位（例如chunks.n缺失、files.length被人工修改）——此时filemd5仍匹配，但读取会失败或返回错误内容 - 不同文件偶然产生相同 MD5（极低概率，但非零；尤其在旧版驱动或非标准写入路径下）
所以，filemd5 适合做第一层快速筛重，但确认“是否真可互换”，必须结合读取验证：尝试用 bucket.openDownloadStream(fileId) 读出完整数据，并比对本地原始文件的 MD5。
绕过驱动、直查 chunks 验证底层一致性
驱动默认缓存并自动拼接 chunk，容易掩盖单个 chunk 损坏或错序问题。若发现某组 filemd5 重复但文件行为异常（如一个能打开、另一个解压失败），需下沉到 chunks 层验证：
- 检查每个文件的 chunk 数量是否等于
Math.ceil(files.length / files.chunkSize)（注意chunkSize可被自定义，默认 255 KiB） - 确认所有
chunks.files_id都存在于files._id中：db.fs.chunks.find({ files_id: { $not: { $in: db.fs.files.distinct("_id") } } }) - 逐个读取疑似重复文件的 chunk，用 BSON 解析器检查
data字段是否为合法二进制——截断、乱码或长度异常即表示该 chunk 存储损坏
聚合结果里出现重复但无法删除？注意事务与引用约束
GridFS 不支持多文档事务，files 和 chunks 是两个独立集合。删除一个文件必须同时删 files 文档和所有关联 chunks 文档，否则残留 chunk 会变成“孤儿”。
安全删除重复项的操作顺序必须是：
- 先记下要保留的
_id（比如最早写入的那个） - 再用
bucket.delete(fileId)删除其余副本（推荐，因它自动清理关联 chunk） - 切勿直接
db.fs.files.remove()——这会导致chunks积压，后续bucket.find()可能报GridFSFileNotFound
真正难处理的不是“怎么找重复”，而是“删完之后，有没有 chunk 残留、有没有其他服务正拿着旧 _id 在读”。线上操作前务必在测试库跑通全链路验证。
