健康判断关键看health与stateStr是否一致、uptime与lastHeartbeatRecv是否匹配、optime是否滞后及syncingTo是否有效，再结合electionTimeoutMillis和term观察选举稳定性。
看到 rs.status() 输出别急着翻文档——关键字段就那几个，盯住它们 30 秒内就能判断节点是否真健康。
health 和 stateStr 必须一起看
health 是心跳连通性的硬指标：0 表示其他成员完全收不到它的心跳，1 才算“在线”；但 stateStr 是逻辑状态，比如 "OTHER" 或 "RECOVERING"。两者不一致时（如 health: 1 但 stateStr: "OTHER"），说明网络通了，但节点自己卡在某个内部流程里，比如同步源不可达、oplog 断档、或配置中 host 字段解析失败。这种问题重启无效，必须查 rs.conf() 里的 members[n].host 是否能被所有节点 DNS 解析。
uptime 和 lastHeartbeatRecv 揭露“假在线”
如果 uptime 很小（比如刚过 10 秒），但 lastHeartbeatRecv 时间戳远早于当前时间（差几十秒），说明该节点虽然启动了，却没真正加入副本集——可能卡在 STARTUP2 阶段，或因磁盘满、权限不足导致初始化失败。此时 rs.status() 里往往看不到它的 optime 字段，或 optimeDate 是 Unix epoch（ISODate("1970-01-01T00:00:00Z")），这是典型的初始同步未开始信号。
optime 和 syncingTo 指向数据一致性瓶颈
optime 是该节点已应用的最新操作时间戳，syncingTo 是它当前从哪个节点拉取 oplog。常见陷阱：
- 若
syncingTo为空，但stateStr是"SECONDARY"，说明它已脱离同步链路，可能是原同步源宕机后没自动切换，需手动执行rs.syncFrom("xxx:27017") - 若
optimeDate比主节点rs.status().members[0].optimeDate落后超过 5 分钟，且syncingTo指向一个健康的PRIMARY，大概率是网络带宽不足或磁盘 I/O 延迟高，不是配置问题 -
optimeDurable明显滞后于optime，说明写入 journal 还没刷盘，要检查storage.journal.enabled是否为true，以及磁盘是否只读
electionTimeoutMillis 和 term 反映选举稳定性
electionTimeoutMillis 默认 10000（10 秒），但它不是固定值——实际超时窗口会动态漂移（+/- 20%）。如果频繁发生主节点切换，先确认所有节点的系统时间是否同步（ntpq -p），再看 term 字段是否在短时间内猛增（比如 5 分钟内从 100 跳到 115）。term 非递增即异常，说明有节点反复尝试发起无效选举，根源常是网络分区或某节点长期处于 "ROLLBACK" 状态未清理干净。
真正难缠的从来不是字段看不懂，而是 health: 1 和 stateStr: "SECONDARY" 同时成立，但应用读请求却随机超时——这时候得立刻切到 mongosh 里跑 db.adminCommand({connPoolStats: 1})，看连接池里有没有大量 "host" 指向已下线节点的残留连接。
