gridfs上传超时后必须手动清理脏数据，因其无事务回滚机制：openuploadstream触发即写入fs.files文档，而fs.chunks异步分批写入，超时会导致元数据异常（如length:0或uploaddate:null）及孤立chunks残留。
GridFS上传超时后为什么必须手动清理脏数据
因为GridFS没有事务回滚机制，openUploadStream一旦触发，fs.files文档就立即插入（哪怕只写入了0个chunk），而fs.chunks写入是分批异步的。超时中断时，你大概率得到一个length: 0或uploadDate: null的元数据文档，外加若干孤立chunks——这些不会自动消失，也不会被后续同名上传覆盖。
怎么定位超时产生的脏文件
别依赖uploadDate范围粗筛，容易漏掉未设时间戳的记录。重点查三类异常：
-
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.deleteMany({files_id: {$in: [ObjectId("..."), ObjectId("...")]}})，传入上一步查出的所有_id数组 - 再执行
db.fs.files.deleteMany({_id: {$in: [ObjectId("..."), ObjectId("...")]}}) - 生产环境务必加
limit(100)分批跑，避免长事务阻塞写入；可用db.fs.chunks.find().limit(100).toArray().map(...)控制批次
上传前加uploadId能大幅降低清理难度
不靠文件名或时间戳判断“是不是同一个上传”，而是上传前生成唯一uploadId（如UUID），写进metadata.uploadId。这样清理时只需：
-
db.fs.files.find({"metadata.uploadId": "xxx"})拿到所有疑似中断的候选 - 对每个匹配项，按
_id精准删其chunks和files文档 - 避免因重名、并发上传导致误删——这是最容易被忽略的设计前提
没有uploadId的系统，每次清理都得人工核对filename和业务上下文，稍有不慎就删错。
