gridfs同名文件默认不覆盖，本质是多版本共存；每次上传生成新文档，_id和uploaddate不同，fs.chunks独立；查询需sort({uploaddate:-1}).limit(1)取最新版，否则可能返回任意版本。
GridFS同名文件默认不覆盖，本质是多版本共存
GridFS本身没有“版本号”字段，但天然支持同名文件多存——每次上传同名文件，fs.files中会生成新文档，_id不同，uploadDate不同，fs.chunks也完全独立。这不是 bug，是设计特性。你查gridFSBucket.find({ filename: "report.pdf" })，默认返回所有历史版本，按uploadDate降序排列。
用 uploadDate + sort 实现“最新版优先”读取
业务上最常需要的是“取最新上传的同名文件”，而非全部列出。这时不能只靠filename查询，必须显式加排序和限制：
-
find({ filename: "report.pdf" }).sort({ uploadDate: -1 }).limit(1)—— Node.js 驱动写法，确保拿到最新版 - 如果用
findOne()，它默认不排序，可能命中任意一个同名文档（取决于索引顺序），结果不可控 - 注意：MongoDB 6.0+ 对
fs.files.filename加了唯一索引（若启用 bucketName 默认索引），但该索引默认不包含uploadDate，所以sort + limit仍需全扫描匹配项，大数据量时建议补复合索引：db.fs.files.createIndex({ filename: 1, uploadDate: -1 })
手动加 version 字段实现语义化版本控制
若需明确区分 v1.0 / v2.1 等语义版本，不能依赖uploadDate，应在metadata里写入version字段：
- 上传时指定：
metadata: { version: "2.1", author: "alice" } - 查询特定版本：
find({ filename: "report.pdf", "metadata.version": "2.1" }) - 查最新语义版本（如取最大 version 字符串）：需应用层解析 version 字符串（如用 semver 库），MongoDB 原生不支持语义化 version 排序
- 避免把 version 放根级字段（如直接写
version: "2.1"），因 GridFS 协议不保证根级自定义字段的兼容性；务必塞进metadata对象内
rename() 和 delete() 对同名多版本的影响要特别小心
这两个操作在多版本场景下极易误伤：
-
rename()只作用于单个文件（由_id定位），安全 —— 它改的是目标文档的filename，不影响其他同名文档 -
delete()是物理删除，且mongofiles delete xxx或驱动delete()方法默认删所有同名文件，不是只删最新版。这是最常见误操作来源 - 逻辑删除（更新
metadata.status）更可控，但同样要基于_id精确更新，否则可能批量误标 ——updateOne({ _id: ObjectId("...") }, { $set: { "metadata.status": "deleted" } })才是正确姿势
sort或_id限定，结果随机返回一个旧版本。
