GridFS 文件不能直接用 updateMany 重命名，因仅改 filename 会导致元数据与 chunks 不一致；安全做法是通过驱动的 rename() 方法原子性插入新条目并删除旧条目。
GridFS 的 files 集合不能直接用 updateMany 安全重命名文件
因为 GridFS 文件名实际存储在 files 集合的 filename 字段，但仅更新它会导致 chunks 与 files 元数据不一致——MongoDB 不会自动同步或校验。你改了 filename，但旧的下载路径、驱动识别、甚至某些客户端缓存仍可能指向原名，更严重的是：如果应用依赖 _id + filename 组合做去重或版本控制，单改 filename 会破坏语义一致性。
真正安全的做法是「逻辑重命名」：插入新条目 + 删除旧条目，而非就地修改。但如果你明确接受风险且只用于内部管理（如批量清理测试数据），可临时操作，需同时满足：
-
files和chunks集合必须在同一个数据库下（默认是fs.files/fs.chunks） - 确保没有客户端正在上传/下载该文件（
uploadDate和length应稳定） - 必须原子性更新
files.filename和对应chunks中的files_id引用（但chunks本身不含filename，所以通常不用动）
为什么不能只跑一条 db.fs.files.updateMany()
常见错误是写这样的命令：
db.fs.files.updateMany(
{ "filename": { $regex: "^old_prefix_" } },
{ $set: { "filename": "new_prefix_" + "$filename" } }
)
这会失败，因为 MongoDB 不支持在 $set 中拼接字符串（"new_prefix_" + "$filename" 是 JS 表达式，不是服务端操作符）。你得用 $concat 聚合管道更新（4.2+）：
db.fs.files.updateMany(
{ "filename": { $regex: "^old_prefix_" } },
[ { $set: { filename: { $concat: ["new_prefix_", "$filename"] } } } ]
)
但注意：$concat 只处理字段值，不会帮你校验目标 filename 是否已存在（GridFS 不强制唯一约束），也不更新任何外部索引或应用层缓存。
真正批量重命名的推荐做法：用驱动代码逐个 rename()
官方 GridFS API 提供了原子重命名方法，例如 Node.js 的 GridFSBucket：
const bucket = new GridFSBucket(db, { bucketName: 'fs' });
const cursor = bucket.find({ filename: { $regex: /^old_/ } });
for await (const file of cursor) {
await bucket.rename(file._id, file.filename.replace(/^old_/, 'new_'));
}
这个 rename() 内部做了三件事：插入新 files 条目、复制 chunks 引用、删除旧 files 条目——全部在单次事务中（若启用副本集或分片集群则需额外配置事务支持）。Python 的 pymongo 同理，用 bucket.rename(file_id, new_name)。
关键点：
- 必须用
file._id作为第一个参数，不能用filename查找后直接传名字（因为可能重名） - 重命名后，旧
filename立即不可读（find不再命中），新名立即生效 - 如果中途失败，旧文件仍完整保留，无数据丢失风险
绕过驱动、纯 Shell 批量重命名的危险边界
极少数场景（比如驱动不可用、紧急修复），你可能想用 mongosh 脚本硬干。这时必须手动配对 files 和 chunks：
db.fs.files.find({ filename: { $regex: "^temp_" } }).forEach(f => {
const newname = f.filename.replace(/^temp_/, "prod_");
// 先检查是否已存在同名
if (db.fs.files.countDocuments({ filename: newname }) === 0) {
db.fs.files.updateOne({ _id: f._id }, { $set: { filename: newname } });
}
});
但这只是「元数据层面」的 rename。容易被忽略的坑：
-
md5字段不会变，但某些审计系统可能把filename+md5当作文件指纹，此时指纹失效 -
uploadDate保持不变，导致按时间排序时新名文件“显得很老” - 如果应用使用
filename做 CDN 缓存 key，重命名后旧缓存不会自动失效
这些细节在自动化脚本里几乎无法补救，只能靠业务层兜底。
