GridFS 不校验文件名唯一性，同名文件可共存于 fs.files，需用 ObjectId 检索；业务需覆盖时应先删旧再传新，或改名（如加时间戳、SHA256哈希）；小文件建议 chunkSizeBytes 设为 4KB 以提升查询性能。
GridFS 默认不校验文件名唯一性，冲突靠应用层控制
GridFS 本身不限制同名文件上传，fs.files 集合中可以存在多个 filename 字段值相同的文档。这意味着直接用 filename 查询（如 findOne({ filename: "report.pdf" })）可能返回任意一个匹配项，而非最新或预期的那个。
根本原因在于 GridFS 的设计目标是分块存储大文件，不是文件系统替代品 —— 它把唯一性保障交给了上层逻辑。
- 每次
uploadFromStream()都会生成新_id（默认为ObjectId），对应独立的fs.files+fs.chunks记录组 -
filename字段仅作元数据使用，不建唯一索引（除非你手动加） - 如果业务要求“同名覆盖”，必须显式删除旧文件再上传，GridFS 不提供原子性 rename 或 upsert 语义
用 ObjectId 检索最可靠，但要注意它存于 fs.files._id 而非文件内容里
每个 GridFS 文件在 fs.files 中有唯一 _id（通常是 ObjectId），而对应的数据块存于 fs.chunks 的 files_id 字段。这是唯一真正可靠的检索锚点。
常见误操作是试图从文件流或 buffer 里反推 ObjectId —— 不可能。它只在写入时由驱动生成并返回，必须由应用保存。
- 上传后务必捕获返回的
ObjectId：const { _id } = await bucket.uploadFromStream("photo.jpg", stream); // _id 是 ObjectId 实例 - 后续读取用
find({_id: _id})或openDownloadStream(_id)，不要尝试用filename当主键 - 若用字符串形式存储
_id，记得用new ObjectId(str)转回对象再查询，否则查不到（BSON 类型不匹配）
想按文件名查又避免冲突？加时间戳或哈希后缀是最快落地方案
如果 UI/接口必须支持“通过原始文件名下载”，又不能接受随机覆盖，推荐在上传时主动改名，而不是依赖索引或事务兜底。
MongoDB 5.0+ 虽支持多文档事务，但 GridFS 的 uploadFromStream 和 delete 无法包进同一个事务（底层涉及两个集合的写入，且驱动未封装原子操作）。
- 安全做法：上传前拼接时间戳，如
`${Date.now()}-${originalName}`，保证全局唯一 - 更优做法：计算文件内容 SHA256，用
sha256 + ext命名（相同内容只存一份，节省空间） - 若必须保留原名，可额外建一张映射表（
filename → _id），每次上传更新该映射，但需自行处理并发写入竞争
别忽略 chunkSizeBytes 对检索性能的影响
虽然和文件名冲突无直接关系，但很多人在按 ObjectId 查文件时发现延迟高，最终定位到 chunk 大小设置不合理。
默认 chunkSizeBytes=255KB，对小文件（比如几 KB 的图标）会产生大量碎片块，查询时要聚合更多 fs.chunks 文档，IO 开销陡增。
- 上传小文件为主时，设
chunkSizeBytes: 4096（4KB）更合适 - 上传大视频为主时，可提到
1024 * 1024（1MB），减少 chunk 文档数量 - 修改 chunk 大小必须在新建
GridFSBucket时指定，已有文件不受影响
实际项目里，文件名冲突问题往往暴露在灰度发布或定时任务重跑场景下——用户没感知，但后台日志里一堆重复 filename 却查不到最新版。这时候翻出当初存的 _id 才发现早被丢弃了。
