priority 0节点在5.0和6.0中行为一致：不能参选主节点但可投票、同步数据、服务读请求并参与写关注；6.0仅增强配置校验与对冲读应对，未改变priority语义。
priority 0 节点在 5.0 和 6.0 中行为一致
从 MongoDB 5.0 到 6.0，priority: 0 的语义和实际效果没有变化：该节点既不能成为主节点，也不会主动发起选举，但仍可参与投票（只要 votes: 1）、同步数据、服务读请求，并确认写关注（如 w: "majority"，前提是它有投票权）。官方文档在两个版本中对这一行为的描述完全一致，不存在“6.0 改变了 priority 0 行为”的情况。
常见误判点是认为 6.0 引入了新选举协议导致 priority 生效逻辑不同——实际上，protocolVersion: 1（即 pv1）早在 3.2 就已默认启用，5.0 和 6.0 都基于它运行。pv1 主要优化的是故障检测速度与多主冲突识别，不改变 priority 的选举权重计算方式。
electionTimeoutMillis 默认值未变，但影响更敏感
settings.electionTimeoutMillis 在 5.0 和 6.0 中默认仍是 10000（10 秒），但 6.0 对网络抖动更敏感，尤其在启用了 catchUpTimeoutMillis 或配置了严格写关注时，心跳超时后触发的选举可能更快进入“等待追赶”阶段，而非立即投票。
- 若副本集中存在延迟较高的
priority: 0节点，6.0 更倾向于先等它追上 oplog 再推进选举（受catchUpTimeoutMillis控制），而 5.0 可能跳过该等待直接开始投票 - 这意味着：相同网络条件下，6.0 副本集在主节点宕机后首次选出新主的时间可能略长（但更稳妥），而 5.0 可能更快但存在短暂双主风险
- 调整建议：若业务对故障转移延迟极度敏感，且能接受极小概率的写回滚，可在 6.0 中将
catchUpTimeoutMillis设为0或极小值
rs.reconfig() 在 6.0 中对版本混搭更严格
5.0 允许在部分成员尚未升级到 5.0 时执行 rs.reconfig()，只要配置语法兼容；而 6.0 的 rs.reconfig() 会显式拒绝包含低于 6.0 版本成员的配置更新，报错类似："Cannot reconfigure replica set with members running different versions"。
这并非选举机制差异，而是配置校验增强。实际影响是：升级过程中若想动态调低某旧版从节点的 priority，必须先完成全集群升级，或改用 rs.stepDown() + 手动干预方式绕过 reconfig。
容易踩的坑：
– 不要在 6.0 主节点上执行含 5.0 成员的 rs.reconfig(cfg)，会失败
– 降级操作（比如把 6.0 集群临时切回 5.0 配置）在 6.0 中不可逆，需先全量降级再 reconfig
隐藏节点（hidden: true）与 priority 0 的组合使用更关键
6.0 并未新增隐藏节点特性，但它强化了对“地理隔离 + 角色分离”场景的推荐实践：一个跨数据中心副本集，若远端中心只用于本地读，应同时设置 priority: 0 和 hidden: true。
原因在于：6.0 的驱动程序默认启用 hedged reads（对冲读），若远端节点未设 hidden: true，即使 priority: 0，它仍可能被客户端选中发起读请求，从而暴露高延迟问题。
正确做法：
– 远端从节点：设 priority: 0 + hidden: true + votes: 1（保持投票权）
– 同一数据中心内至少保留 3 个 priority ≥ 1 且 votes: 1 的节点，确保法定人数不依赖远端
这个组合在 5.0 中可用，但在 6.0 中已成为规避对冲读副作用的事实标准。
