gridfs同名上传不会覆盖旧文件，而是生成新_id并保留旧文件；安全覆盖需三步：查最新_id、上传新文件、再删旧_id；仅凭filename删除会误删多版本，可靠锚点唯有唯一_id。
GridFS 不会自动覆盖同名文件，每次上传都生成新 _id，旧文件残留，必须手动删旧再传新。
GridFS 同名上传到底发生了什么
调用 bucket.openUploadStream() 或 bucket.uploadFromStream() 上传同名文件时，MongoDB 完全不检查 filename 是否已存在。它会：
- 在
fs.files中插入一条新文档，_id是全新ObjectId - 在
fs.chunks中写入一批新块，files_id指向这个新_id - 旧文件的
fs.files文档和对应fs.chunks块全部保留，不受影响
结果就是：查 filename 会返回多条记录，bucket.find({ filename: "xxx.jpg" }) 可能拿到任意一个版本——不是最新，也不是你刚传的那个。
安全覆盖的三步操作（必须按顺序）
所谓“覆盖”，本质是应用层组合操作，没有原子性保障。关键步骤缺一不可：
- 先用
bucket.find({ filename: "xxx.jpg" }).sort({ uploadDate: -1 }).limit(1)查出当前最新版本的_id（别用findOne，避免命中旧版本） - 调用
bucket.openUploadStream()上传新文件，拿到返回的uploadStream的_id - 确认上传成功后（即
uploadStream.on("finish", ...)触发），再执行bucket.delete({ _id: oldId })删除旧文件
注意：bucket.delete() 会同时删掉 fs.files 和对应所有 fs.chunks，不用自己清理块。
为什么不能只依赖 filename 查询和删除
bucket.delete({ filename: "xxx.jpg" }) 是危险操作，它会删除所有匹配的文件，不只是最新那个。常见后果：
- 误删多个历史版本（比如用户头像不同尺寸裁剪图都叫
avatar.jpg） - 并发上传时，A 刚查到旧
_id，B 又上传了新版本，A 删除时把 B 的也干掉了 -
mongofiles delete xxx.jpg命令同理，底层也是按filename批量删
真正可靠的锚点只有 _id —— 它唯一、不可变、且与 chunks 强绑定。
高频覆盖场景下的隐藏风险
删旧 + 传新之间存在时间窗口，CDN 回源或客户端直读可能遇到 404 或旧内容。这不是代码 bug，而是 GridFS 架构决定的：
- 上传中断时，
fs.files已写入但fs.chunks缺失部分块，形成“孤儿元数据”，bucket.openDownloadStream()直接报FileNotFound - 事务无法包裹 GridFS 操作，
session.startTransaction()对openUploadStream()无效 - 清理孤立 chunk 需单独跑聚合查询：
db.fs.chunks.aggregate([ { $lookup: { from: "fs.files", localField: "files_id", foreignField: "_id", as: "files" } }, { $match: { "files.0": { $exists: false } } } ])
最易被忽略的点：所有读取逻辑必须接受“版本切换”而非“内容更新”——比如前端请求 /file/avatar.jpg 时，服务端应查最新 uploadDate 对应的 _id，而不是缓存一个固定 ID。
