$rename能安全重命名字段，但必须避开嵌套数组（如comments.0.author）、索引失效（需提前建新索引并删旧索引）和覆盖风险（新字段存在时静默覆盖）。
$rename 是唯一原生支持字段重命名的操作符，但它不是“改个名字”那么简单——它本质是原子性地复制值再删除旧字段，必须绕开嵌套数组、索引失效和覆盖风险这三类坑。
为什么直接用 $rename 会报 Cannot rename field inside array
因为 $rename 不支持路径中含数组下标，比如 comments.0.author 或 tags.1。它只认顶层字段或点号分隔的嵌套对象路径（如 user.profile.name），但一旦路径里出现 .0、.1 这类数组索引，操作立刻失败。
- 检查方式：
db.collection.findOne({ "fieldName.0": { $exists: true } })—— 若返回文档，说明该字段可能落在数组里，不能用$rename - 替代方案：只能用聚合更新（4.2+）或应用层逐条处理，例如：
db.collection.updateMany({}, [ {$set: {"user.fullName": "$user.name"}}, {$unset: "user.name"} ])
如何避免重命名后查询变慢甚至超时
字段名一改，原字段上的索引（如 { "oldName": 1 }）立即失效，新字段默认无索引。如果集合大、查询频，性能会断崖式下跌。
- 必须提前建好新字段索引：
db.collection.createIndex({ "newName": 1 })，等db.collection.getIndexes()显示状态为"buildPhase": "completed"再执行$rename - 重命名完成后，手动删掉旧索引：
db.collection.dropIndex("oldName_1")，否则冗余索引拖慢写入 - 注意：复合索引中若只改了其中一个字段名（如从
{a:1, b:1}改b为c），整个索引需重建，不能只 rename 字段
用 updateMany 批量重命名时的常见翻车点
updateMany + $rename 是主力操作，但容易忽略几个关键细节：
-
multi: true已废弃，必须显式调用updateMany，写成update默认只改第一条 - 新字段名若已存在，
$rename会静默覆盖其值，不报错也不警告 —— 务必先用db.collection.find({ newName: { $exists: true } }).count()确认为空 - 执行后必须验证迁移比例：
db.collection.countDocuments({ newName: { $exists: true } })和db.collection.countDocuments({ oldName: { $exists: true } })，两者之和应等于总数
Compass 里怎么安全做字段重命名
Compass 的 Bulk Update 模式能预览效果，适合小批量或验证场景，但有硬限制：
- Filter 栏留空表示全量更新；Update 栏填：
{ $rename: { "oldName": "newName" } } - Preview 不显示索引变化，所以建新索引、删旧索引这些必须在 Shell 里手动完成
- 不支持事务预览，如果集合在更新中途被其他写入干扰，Preview 结果可能不准 —— 生产环境建议避开高峰时段执行
最易被忽略的是：重命名只是字段名变了，应用代码、聚合管道、校验规则（如 JSON Schema）、甚至前端字段映射都得同步改。漏掉任意一环，就不是“平滑迁移”，而是线上事故前奏。
