GridFS本身不提供版本管理能力，version字段需手动维护递增、is_current标记及旧版失效逻辑；get_last_version()默认按uploadDate而非version排序，须显式查询并建索引；并发写入需用findOneAndUpdate或事务保证原子性；旧版本不会自动清理，须定期删除以避免磁盘膨胀。
直接在 GridFS 元数据中加 version 字段可行，但必须配合手动维护逻辑 —— GridFS 本身不提供版本管理能力，所有“版本递增”“旧版失效”“当前标识切换”都得你自己写代码控制。
为什么不能只靠 version 字段自动生效
GridFS 的 fs.files 集合只是普通文档，metadata.version 是自定义字段，MongoDB 不会据此做任何特殊处理。你存 10 个同名文件、每个 version 不同，它就真存 10 条独立记录，不会自动归档或隐藏旧版。
- 没有内置的“覆盖上传即升版”语义 ——
uploadFromStream('report.pdf')每次都是新插入一条fs.files文档 -
is_current: true这种标记完全靠应用层写入/更新，一旦漏掉或并发冲突，就会出现多个is_current: true或全为false - 查询“最新版”必须显式用
findOne({ filename: 'x', 'metadata.is_current': true })，不能依赖 GridFS 原生方法
get_last_version() 在 PyMongo 中可用，但有前提
PyMongo 的 gridfs.GridFS.get_last_version() 确实能按文件名返回最高 version 的文件，但它只检查 filename 和 uploadDate，**不看你的自定义 version 字段** —— 除非你重写该方法或改用 find() 手动排序。
- 默认行为：按
uploadDate降序取第一条，和version无关 - 要按
version排序，得自己查：fs.find({'filename': 'x'}).sort('metadata.version', -1).limit(1) - 注意：如果没建索引，
sort('metadata.version')可能全表扫描，大库下变慢
如何安全地写入新版本（避免并发错乱）
关键不是“怎么加字段”，而是“怎么原子性地更新状态”。推荐用 MongoDB 的 findOneAndUpdate + upsert 组合，一次性完成：查当前版 → 设旧版 is_current: false → 写新版并设 is_current: true。
- 不要分两步：先
findOne再updateMany+upload，中间可能被其他请求插入 - 用事务（4.0+）包裹更稳妥，尤其当你要同时更新元数据和业务表时
- 示例逻辑（Node.js）：
const result = await bucket.find({ 'filename': name, 'metadata.is_current': true }).toArray(); const oldId = result[0]?._id; if (oldId) { await db.collection('fs.files').updateOne( { _id: oldId }, { $set: { 'metadata.is_current': false } } ); } // 然后 upload 新文件，并在 metadata 里带 version 和 is_current: true
容易被忽略的存储成本与清理盲区
每存一个新版本，GridFS 就多存一份完整文件块（fs.chunks），哪怕只有几字节改动。旧版文件不会自动删除，也不会自动去重。
- 如果你没定期运行
delete({ 'metadata.is_current': false })清理旧版，磁盘会持续膨胀 - GridFS 不支持“增量 diff 存储”，无法像 Git 那样只存变更部分
- 想省空间？得自己实现内容哈希比对，相同内容跳过上传 —— 但要注意：哈希碰撞风险、计算开销、是否允许不同
version对应相同二进制
