在 MongoDB 的 GridFS 中，官方并未直接提供 rename() 方法。若想为文件更换名称，实际只需更新 files 集合里对应文档的 filename 字段。但有几个关键点必须留意：确保 bucket 名称与 _id 保持一致，chunks 集合完全无需调整；倘若需要跨 bucket 或修改 _id，操作就会变得复杂——必须先读取数据、写入新记录、再删除旧记录，并且借助事务来保障一致性。
GridFS 缺少 rename() 方法，无需费力寻找
MongoDB 官方 GridFS 接口——无论是 pymongo、mongo-go-driver 还是 Node.js 的 mongodb 包——都不提供直接重命名文件的函数。这不是文档遗漏，而是确实不存在。GridFS 的核心机制是将文件拆分为 chunks 和 files 两个集合进行存储，元数据仅保存在 files 文档中。因此重命名 = 修改该文档的 filename 字段，但必须自行确保不破坏两者之间的关联。
借助 update_one 更新 files 集合的 filename 字段
这是最轻量、最常用的做法，适用于绝大部分场景：文件内容不变，仅更换逻辑名称。关键不是“移动”，而是“标记一个新名字”。
- 必须同时满足两个条件：
bucket名称一致（默认是fs），_id或其他唯一字段能准确定位原文件（建议使用_id，避免同名冲突）。 - 只更新
files集合，chunks集合完全不动——它们靠files_id关联，根本不依赖filename。 - 有一点需要特别留意：如果应用层依赖
filename进行唯一查找（比如使用find({"filename": "old.jpg"})），改名之后旧查询就会失效。
使用 PyMongo 时，操作十分简洁：
db.fs.files.update_one(
{"_id": old_file_id},
{"$set": {"filename": "new-name.pdf"}})
rename() 被误用时的典型报错与陷阱
搜索到某些博客提到 bucket.rename() 或 gridfs.rename()，这些内容基本已经过时，或者混淆了驱动版本。真实环境下常见的坑包括：
AttributeError: 'GridFSBucket' object has no attribute 'rename'——pymongo >= 4.0已移除此方法。- 手动对
fs.files集合调用rename命令：MongoDB 不支持对非system.*集合执行renameCollection，会报CommandNotSupportedOnView。 - 并发修改风险：两个请求同时更改同一个
filename，可能会互相覆盖。建议启用upsert=False，并检查返回的matched_count来确认是否真正修改成功。
需要真正“迁移”文件时（例如更换 bucket 或修改 _id）
这已经超出“重命名”的范畴，属于完整的文件迁移操作。必须读取原始数据、写入新条目、再删除旧条目。性能较差且存在中间态风险，只有业务强依赖 _id 或 bucket 隔离时才值得采用。
- 不能跳过读取：GridFS 不支持服务器端 copy，
copyTo这类方法在现代驱动中基本废弃。 - 务必使用事务（前提是 MongoDB 版本 ≥ 4.0 且采用 replica set）将“写新 + 删旧”包裹起来，否则可能丢失文件。
- 注意内存：大文件要流式处理，切勿一次性
read()进内存；使用download_to_stream+upload_from_stream才是正确方式。
简单总结：95% 的“改名”需求，仅需修改 files.filename 即可；剩下那 5%，只能接受额外的 IO 和事务开销。
最容易被忽视的一点是：应用缓存、CDN URL、前端已保存的下载链接，都不会随数据库字段更新而自动失效。名字虽然改了，但外部引用仍指向旧路径。
