分片集群中不能直接修改sharded集合schema，必须直连各shard主节点按chunk切片执行updateMany，且需停均衡、校验状态、分步处理null/缺失字段、控制应用读写并验证一致性。
分片集群里直接改 collection schema 会失败
MongoDB 分片集群不支持在 sharded 集合上直接执行 collMod 或带 $set 的 updateMany 全量更新——不是语法报错，而是操作会被路由到错误的 shard，或被 mongos 拦截拒绝。你看到的典型错误是：Cannot update sharded collection without shard key in query 或 NotMasterNoSlaveOk，本质是写请求没按分片键路由，触发了安全保护。
真正能走通的路径只有一条：绕过 mongos，直连每个 shard 的主节点，单独执行变更。但必须确保所有 shard 同时处于可写、无滚动迁移、无 chunk 均衡状态，否则数据不一致风险极高。
- 先用
sh.status()确认没有balancing: true和正在迁移的 chunk - 检查每个 shard 的 primary 是否在线：
rs.status()中stateStr === "PRIMARY" - 禁用自动均衡：
sh.setBalancerState(false)，等当前迁移完成再操作
全量扫表更新必须按 shard 键范围切片并发
不能对整个集合发一个 updateMany({})——mongos 会把它广播到所有 shard，但每个 shard 只处理自己持有的 chunk，而你无法控制并发粒度和内存占用。结果要么 OOM，要么锁表太久导致应用超时。
正确做法是：查出每个 shard 上该 collection 的 chunk 分布，按 min/max 范围切分成小批次，每个批次单独发起 updateMany 请求到对应 shard 的 primary。
- 用
db.collection.getShardDistribution()或查config.chunks获取 chunk 边界 - 每个请求必须带上分片键条件，例如
{ shardKey: { $gte: minVal, $lt: maxVal } } - 加
{ multi: true, writeConcern: { w: "majority" } }，避免部分写入成功 - 单批次文档数建议 ≤ 10k，避免单次操作耗时过长（可通过
explain("executionStats")验证）
字段新增/默认值填充要区分 null 和缺失字段
在分片集合里执行类似 { $set: { newField: "default" } } 时，newField 对已存在但值为 null 的文档不会覆盖，但对完全缺失该字段的文档会新增。这看起来合理，但实际线上数据常混杂两种状态，导致语义不一致。
更稳妥的方式是显式区分处理：
- 先补缺失字段：
updateMany({ newField: { $exists: false } }, { $set: { newField: "default" } }) - 再统一覆盖 null：
updateMany({ newField: null }, { $set: { newField: "default" } }) - 注意：这两个操作都必须按 chunk 切片执行，不能在
mongos层做，否则又触发路由问题 - 如果字段类型需变更（如 string → number），务必加类型校验逻辑，避免
$set把字符串塞进数字字段报错
变更期间应用读写行为必须可控
即使你把更新切得很细、每个请求都成功，只要应用还在持续写入，就可能产生“新旧混合”数据：一部分文档已有新字段，一部分还没有；甚至同一文档在更新中途被应用修改，导致字段被意外清空。
最轻量的控制方式不是停写，而是用写前钩子（write concern + 应用层标记）+ 短窗口只读：
- 提前在应用配置中灰度开关，让新流量写入时自动带上
schemaVersion: 2 - 变更窗口内，对老字段读取逻辑做兼容（比如
doc.newField ?? doc.oldField） - 禁止在变更过程中执行涉及该集合的
findAndModify或事务——它们可能跨 chunk，路由不可控 - 变更完成后，用
db.collection.validate(true)抽样检查各 shard 数据一致性，别只信日志
最难的不是跑完脚本，而是确认每个 shard 上最后一批 chunk 的更新时间戳是否全部晚于变更启动时间——这个时间对齐点，没人帮你盯，得自己从 oplog 或应用日志里交叉验证。
