GridFS写入中断后必须手动清理，因其无事务回滚机制：openUploadStream触发即写入fs.files文档，而fs.chunks异步分批写入，中断会导致length:0或uploadDate:null等元数据异常及孤立chunks残留。
GridFS写入中断后必须手动清理，因为没有事务回滚机制——openUploadStream一触发，fs.files文档就已写入，而fs.chunks是异步分批写入的，中断必然导致元数据异常和孤立chunks残留。
怎么快速定位中断产生的脏文件
别依赖uploadDate范围筛选，容易漏掉uploadDate: null或未设时间戳的记录。重点查三类异常：
-
fs.files中length: 0且metadata.status: "uploading" -
fs.files中uploadDate: null，或uploadDate明显早于当前时间但length > 0却查不到对应chunks - 用聚合比对实际字节数：
db.fs.files.aggregate([{$match: {uploadDate: {$gt: ISODate("2026-05-01")}}}, {$lookup: {from: "fs.chunks", localField: "_id", foreignField: "files_id", as: "chunks"}}, {$addFields: {actualSize: {$sum: {$size: "$chunks.data"}}}}, {$match: {$expr: {$ne: ["$actualSize", "$length"]}}}] )
清理脚本必须分两步，顺序不能错
先删fs.chunks，再删fs.files。MongoDB不支持跨集合事务，反过来删会留下永久性孤儿块。
- 分批执行，避免长事务阻塞写入；可用
db.fs.chunks.find().limit(100).toArray().map()控制批次 - 如果业务已加
uploadId（如UUID），清理时只需：db.fs.files.find({"metadata.uploadId": "xxx"})拿到候选，再按每个_id精准删其chunks和files文档 - 没
uploadId的系统，每次清理都得人工核对filename和业务上下文，稍有不慎就删错——这是最容易被忽略的设计前提
为什么直接删fs.files不行
mongosh 直接执行db.fs.files.deleteMany()不触发任何自动清理，它只是删掉元数据文档，fs.chunks会全部残留成孤儿块。即使你用官方驱动调用bucket.delete()，也只在传入合法ObjectId时才生效；若传字符串文件名，会静默失败或报错。
真正麻烦的不是删不掉，而是删完看不见效果：磁盘空间不会立即释放，fs.chunks残留、索引未优化、files_id字段缺索引都会让后续清理越来越慢。生产环境上线前，务必确认db.fs.chunks.createIndex({"files_id": 1})已建好。
