gridfs不支持版本控制，需用业务id替代filename作主键并维护is_latest字段实现原子版本更新。fs.files.filename无唯一约束，同名文件会堆积；应建metadata.doc_id与metadata.is_latest复合索引，并在新文档中存previousversionid以支持回退。
GridFS 本身不支持版本控制，version 字段必须手动写入 metadata，且需配合原子更新、索引和业务 ID 才能可靠工作。
为什么 fs.files.filename 不能当版本标识用
每次调用 $bucket->uploadFromStream() 都会插入一条全新 fs.files 文档，filename 字段无唯一约束，同名文件可无限堆积。你看到的“覆盖”只是应用层没做清理，数据库里实际是多条并存记录。
后果包括：
- 查最新版要全表扫描
fs.files，性能随版本数线性下降 - 大小写、空格、编码差异（如
report.pdfvsReport.PDF）导致匹配失败 - 重命名后历史版本丢失上下文，无法追溯变更链
如何安全写入 version 并保证“最新版”唯一
核心是两步原子操作：先标记旧版为非最新，再上传新版并设 is_latest: true。不能靠时间戳或自增整数自动推导——并发时极易冲突。
推荐做法：
- 用业务 ID（如
doc_id: "INV-2026-001"）替代filename作为主键，filename仅作展示字段 - 上传前执行
$bucket->find(['metadata.doc_id' => 'INV-2026-001', 'metadata.is_latest' => true])查当前最新版 - 拿到结果后，用
updateOne()将其metadata.is_latest改为false - 新文件上传时，
metadata显式传入['doc_id' => 'INV-2026-001', 'version' => 'v1.3.0', 'is_latest' => true]
必须建的复合索引与查询示例
没索引时按 doc_id + is_latest 查询会触发 collection scan，数据量一过万就明显变慢。
在 MongoDB Shell 中运行：
db.fs.files.createIndex({ "metadata.doc_id": 1, "metadata.is_latest": 1 })
这样就能高效查最新版：
$latest = $bucket->findOne(['metadata.doc_id' => 'INV-2026-001', 'metadata.is_latest' => true]);
也支持按版本号查特定版：
$v120 = $bucket->findOne(['metadata.doc_id' => 'INV-2026-001', 'metadata.version' => 'v1.2.0']);
删除旧版本前务必保留 previousVersionId
直接删 fs.files 文档风险极高——万一删完上传失败，就彻底断档。更稳妥的做法是在新文档的 metadata 里存上一版 _id：
"metadata": {
"doc_id": "INV-2026-001",
"version": "v1.3.0",
"is_latest": true,
"previousVersionId": ObjectId("65a1b2c3d4e5f67890123455")
}
这样即使出错，也能立刻回退：
$bucket->findOne(['_id' => $doc->metadata->previousVersionId]);
真正删旧版，应放在整个流程确认成功后的异步任务里，而非主链路。
