必须按官方路径分步升级：先升FCV至5.0再升6.0；严格顺序升级config server、shard、mongos；升级后须逐台执行sh.refreshRouterConfig并验证路由与Balancer状态。
不能直接跳过中间版本升级，必须按 MongoDB 官方指定路径执行分步操作；否则 mongos 路由表会失效、分片元数据不一致，导致查询路由错误甚至写入丢失。
必须先将 FCV 升级到 5.0 再升 6.0
即使所有节点已运行 MongoDB 6.0 二进制文件，若 featureCompatibilityVersion（FCV）仍为 4.4 或 5.0，集群无法启用 6.0 新特性，且部分命令（如 $merge 的某些选项）会报错或行为异常。
- 升级前确认所有节点 FCV 已设为
"5.0"：运行db.adminCommand({getFeatureCompatibilityVersion: 1}) - 若 FCV 是
"4.4"，必须先停机升级到 5.0 并手动执行db.adminCommand({setFeatureCompatibilityVersion: "5.0"}) - FCV 升级不可逆，且要求所有副本集成员在线、状态为
PRIMARY或SECONDARY（不能有STARTUP等临时状态）
分片集群各组件需按严格顺序升级
顺序错误会导致 config server 与 shard 间协议不兼容，mongos 无法识别新分片或路由规则失效。
- 先升级所有
config server副本集（CSRS）：逐个替换mongod进程，确保每个成员启动后能成功加入副本集并完成初始化同步 - 再升级所有
shard副本集：同样逐个滚动升级，避免主节点同时离线；升级完成后检查sh.status()中每个分片的version字段是否已更新 - 最后升级全部
mongos实例：替换二进制后，必须对每个mongos执行sh.stopBalancer()→ 等待迁移完成 →sh.startBalancer()→ 再连接任意mongos运行sh.refreshRouterConfig()
升级后必须验证路由与 Balancer 状态
常见故障不是服务起不来，而是 mongos 缓存了旧路由表，导致新插入数据落到错误分片，或查询只返回部分结果。
- 用
sh.status()检查输出中是否有"stale config"提示；若有，说明某mongos未执行refreshRouterConfig - 执行
sh.getBalancerState()和sh.isBalancerRunning()，确认 Balancer 已真正启动且无阻塞日志 - 在任意
mongos上运行db.runCommand({listShards: 1})，比对返回的host字段是否与实际 shard 地址一致 - 写入测试文档后，用
db.collection.getShardDistribution()验证数据是否按预期分片
最容易被忽略的是 mongos 的配置刷新动作——它不会自动触发，必须人工逐台调用 sh.refreshRouterConfig()。哪怕只漏掉一台，就可能让部分客户端请求持续走错路由，问题在流量高峰时才暴露，排查成本极高。
