副本集连接稳定性取决于显式指定replicaset、启用useunifiedtopology=true、合理设置超时与重试参数，并正确处理认证及密码编码。
副本集连接字符串写对了，不等于连接就稳；真正决定稳定性的，是连接字符串里那些被忽略的重试与拓扑发现参数。
副本集连接字符串必须带 replicaSet 参数
只写多个 host 就以为自动连上副本集？错。MongoDB 驱动默认按 direct 模式处理单 host，多个 host 时也未必自动切换为副本集模式——除非显式声明 replicaSet。
常见错误现象：MongoServerSelectionError: Server selection timed out after 30000 ms，或始终连到某个节点但无法感知主从切换。
-
replicaSet值必须与副本集实际名称完全一致（区分大小写），可通过rs.conf()或db.adminCommand({isMaster:1})确认 - 即使只填一个 host（如
mongodb://node1:27017/?replicaSet=rs0），驱动也会主动探测整个副本集拓扑 - 不带
replicaSet的多 host 字符串（如mongodb://a,b,c）在新版驱动（4.0+）中已不触发副本集逻辑，等效于轮询直连
connectTimeoutMS 和 socketTimeoutMS 不是越大越好
超时设成 60 秒看似“更宽容”，实则拖慢故障发现速度，掩盖拓扑异常，让客户端长时间卡在无效节点上。
-
connectTimeoutMS建议设为5000–10000：足够发现节点存活，又不至于在宕机节点上空等 -
socketTimeoutMS建议设为30000左右：覆盖常规慢查询，但避免阻塞连接池太久 - 这两个值过大会导致重试延迟拉长，尤其在网络分区或某节点假死时，
MongoNetworkError出现得晚、恢复得慢
重试机制依赖 useUnifiedTopology=true 和 retryWrites=true
旧版驱动（useUnifiedTopology=false）用的是已废弃的服务器发现逻辑，无法正确响应主节点切换后的自动重试。
-
useUnifiedTopology=true是启用现代拓扑监控和重试的前提，Node.js 驱动 4.x 起强制要求 -
retryWrites=true（默认开启）仅对满足条件的写操作生效：单文档insertOne/updateOne/deleteOne，且w=majority时才真正重试 - 读操作不自动重试，需靠
readPreference+ 应用层兜底；若设readPreference=secondary却遇到从节点不可读，驱动不会换节点重试，而是直接报错
生产环境必须加 authSource=admin 和 URL 编码密码
认证失败不是“连不上”，而是“连上了却鉴权失败”，错误信息常被误判为网络问题。
- 用户若建在
admin库，authSource=admin必须显式指定；不写会默认去目标库（如/mydb）找用户，必然失败 - 密码含
@、:、/、%时，不编码会导致 URI 解析错乱——例如pass@word会被截成pass用户 + 空密码 + 主机word - 推荐用
encodeURIComponent()处理密码（Node.js）或urllib.parse.quote()（Python），而非手动替换；@ → %40、: → %3A、/ → %2F
最易被忽略的一点：副本集连接稳定性不取决于你写了几个 host，而取决于驱动是否能持续监听 hello（或 isMaster）响应并更新内部拓扑视图。一旦 heartbeatFrequencyMS（默认 10s）探测失败，驱动才会触发节点下线和重选；这个过程完全透明，但前提是你的连接字符串没关掉统一拓扑、没锁死超时、也没把认证搞错。
