GridFS不支持原地修改文件内容，只能通过应用层“删除旧文件+上传新文件”实现更新；其chunk存储机制决定无法覆盖写入，重复上传同名文件会生成全新_id及chunks，旧数据仍保留。
GridFS 从设计上就不支持原地修改文件内容，所谓“更新”只能靠应用层实现“删旧传新”，这不是驱动缺陷，而是架构取舍。
GridFS 的 chunk 存储机制决定了无法覆盖写入
GridFS 把文件拆成 fs.chunks 文档存储，每个 chunk 是独立 BSON 文档，带 files_id 关联到 fs.files 中的元数据。没有“按 offset 修改某个 chunk”的接口，也没有服务端校验或重写逻辑——uploadFromStream() 或 mongofiles put 永远只做一件事：插入新 _id、新 chunks、新 files 文档。
- 重复上传同名文件 →
fs.files多一条记录，fs.chunks多一批文档，旧数据仍完整存在 - 试图用
updateOne({filename: "x"}, {$set: {...}})改fs.files→ 不影响任何fs.chunks，文件二进制内容完全没变 - 手动去
fs.chunks里删/改 chunk → 破坏files_id一致性，驱动读取时会报FileNotFound或拼接错乱
为什么不能加个原子 update 接口？
因为 GridFS 的核心假设是“文件即不可变对象”。MongoDB 官方明确指出：如果需要原子更新整个文件内容，请勿使用 GridFS。它更适合版本化场景（如存 v1/v2/v3）、流式分片读取、跨地域同步等，而非高频编辑。
- 加原子 update 意味着要锁住整个文件链路（
files+ 所有相关chunks），在分布式环境下开销巨大 - 用户上传的“同名文件”可能语义完全不同（比如两个学生都交了
report.pdf），服务端无法安全判定是否该覆盖 - 驱动不计算 MD5 / SHA256，也不比对
length或内容哈希，所以连“是否真相同”都无从判断
删+传看似简单，但容易踩的坑
两步操作非原子，中间出错就会导致文件丢失或状态撕裂。关键不是写几行代码，而是控制好边界条件：
- 别用
filename查旧文件 —— 并发上传时可能拿到错误的_id；必须用业务层生成的唯一_id（如ObjectId）或带版本号的metadata -
bucket.delete(fileId)成功 ≠ 文件已彻底不可见 —— 驱动删除是异步清理chunks，若此时有客户端正在下载，可能读到部分缺失块 - 上传新文件时未指定
_id→ 新旧文件完全解耦，后续无法通过 ID 关联版本；复用旧_id才能维持逻辑连续性 - 没处理失败回滚 —— 例如
delete成功但uploadFromStream()失败，就得靠定时任务扫描孤立chunks或依赖metadata.active字段做软切换
真正难的从来不是“怎么调用 delete 和 uploadFromStream”，而是想清楚：这个“更新”在你系统里到底代表什么——是强制替换？灰度切换？还是仅元数据修订？GridFS 把自由给了你，也把一致性责任一起交了过来。
