GridFS 不支持覆盖写入，重复上传同名文件会创建新文档而非更新旧文件；更新内容需先按唯一标识（如自定义 _id）删除旧文件再上传新版本；仅元数据可安全更新。
不支持直接更新文件内容，GridFS 的设计就是“写一次、读多次”
为什么不能用 put 或 uploadFromStream() 覆盖同名文件？
GridFS 从底层就不提供“覆盖写入”语义。当你重复执行 mongofiles put 或调用 Bucket::uploadFromStream() 上传同名文件时，MongoDB 不会删除旧文件、也不会修改原有 chunk，而是新建一个完整文件记录（新 _id，新 uploadDate，新 chunks）。fs.files 集合里会多出一条文档，fs.chunks 里也会新增一批块——旧文件依然存在，只是被“隐藏”了。
- 这是有意为之：相同
filename不代表相同内容（比如多个学生交的report.pdf） - 驱动不会校验 MD5 或内容哈希，也不比较
length，只管存 - 命令行
mongofiles delete README.txt删除的是所有同名文件，不是“最新那个”，容易误删
想“更新内容”，只能手动删+重传
没有原子化的“update file content”操作。真实可行路径只有两步：先定位并删除旧文件，再上传新版本。关键在“定位”——不能靠 filename，得用唯一标识：
- 最稳妥：上传时自己指定
_id（如ObjectId），后续用该_id精准查删 - 次选：用
metadata打标记（如{"version": "v2", "active": true}），再配合find()+delete()过滤 - 别依赖
filename+uploadDate排序取最新——并发上传时可能错乱
示例（Node.js）：
const fileId = new ObjectId('60a1b2c3d4e5f67890123456');
await bucket.delete(fileId); // 先删
await bucket.uploadFromStream('report.pdf', stream, { _id: fileId }); // 再传，复用_id
元数据可以改，但内容改不了
如果你只是想更新描述、标签、权限等信息，bucket.updateMetadata() 是安全且高效的——它只改 fs.files 文档里的 metadata 字段，不碰 fs.chunks，也不影响文件二进制内容。
- 支持任意 JSON-serializable 数据，比如
{description: "revised", updated_by: "admin"} - 注意：该方法不校验
_id是否真对应一个 GridFS 文件，传错 ID 会静默失败 - 别试图在
metadata里塞大对象（如 Base64 图片），它本就不是存内容的地方
真正难的不是“怎么写代码”，而是想清楚业务里“更新”到底指什么：是替换整个文件？还是仅修正元信息？或是版本化管理？GridFS 把选择权留给你，也把责任留给你。
