直接删 fs.files 会留下孤儿 fs.chunks，因 MongoDB 不保证跨集合原子性；安全清理需先建索引、聚合查 orphan、分批删除；compact 不释放空间需主节点且停写；客户端须校验 ID 存在性及外部依赖。
为什么直接删 fs.files 会留下孤儿 fs.chunks
因为 MongoDB 不保证跨集合操作的原子性。GridFS 驱动（如 Node.js、Go、PyMongo）只有在调用 bucket.delete() 或 deleteOne() 等高层接口时，才会主动触发对 fs.chunks 的级联清理；而你在 mongosh 里执行 db.fs.files.deleteMany({})，只是删掉元数据，fs.chunks 文档全数滞留，变成“孤儿块”——它们的 files_id 指向一个已不存在的 _id，既无法被正常读取，也无法被自动回收。
如何安全识别并批量删除孤儿 fs.chunks
必须先建索引再查，否则聚合慢到超时。执行顺序不能错：
-
db.fs.chunks.createIndex({ "files_id": 1 })—— 加速后续$lookup或$in查询 -
db.fs.chunks.aggregate([ { $lookup: { from: "fs.files", localField: "files_id", foreignField: "_id", as: "file" } }, { $match: { "file.0": { $exists: false } } }, { $project: { _id: 1 } } ])—— 找出所有files_id在fs.files中无匹配的 chunk - 把结果
_id提取为数组，分批删（避免单次操作过大阻塞）：db.fs.chunks.deleteMany({ _id: { $in: [/* id array */] } })
注意：别用 db.fs.chunks.find({ files_id: { $nin: [...] } }) 直接删——$nin 在大数据量下性能极差，且容易因内存溢出失败。
删完孤儿块后，为什么磁盘空间还不释放
WiredTiger 引擎不会自动回收已删除文档占用的物理页，只标记为空闲。你得手动触发 compact，但有两个硬约束：
-
db.runCommand({ compact: "fs.chunks" })仅在副本集 Primary 或分片集群的 shard 节点上生效，单机部署不支持 - 该命令执行期间，
fs.chunks集合完全不可读写，必须安排在低峰期 - 它不替代
reIndex()；建议先db.fs.chunks.reIndex()整理 B-tree 结构，再compact回收空间
另外，fs.files 上也可能积压大量“有 _id 但无任何对应 chunk”的元数据（即孤儿文件），这类文档同样要定期扫描清理，否则碎片反复再生。
Go/Node.js/Python 客户端删除时最容易忽略的一点
不是“怎么删”，而是“删之前有没有确认目标存在”。比如 Go 驱动中调用 bucket.Delete(ctx, id)，如果传入的是字符串而非 ObjectID，或 id 根本不存在，驱动默认静默成功，不报错也不删——你得自己加一层 bucket.Find() 验证返回是否非空，再决定是否执行 Delete。Node.js 同理，bucket.find({ filename: "xxx" }) 不支持嵌套 metadata 查询，条件会被静默忽略，必须用 bucket.s.db.collection("fs.files").find() 绕过 Bucket 层查元数据。
真正难的从来不是命令怎么写，而是删之前没想清楚：这个 files_id 是不是真的已经没人引用？下游服务有没有缓存旧 ID？CDN 是否还在回源？这些不在数据库里的依赖，才是清理动作卡住或引发故障的主因。
