副本集选举期间写操作失败是正常现象，因主节点缺失导致NotWritablePrimary等错误；应设timeoutMS为1000–3000毫秒以快速失败并由业务处理重试，而非延长超时等待。
副本集选举期间写操作失败是正常现象
当主节点宕机或网络分区发生时，MongoDB 副本集会触发选举，这期间（通常几秒内）没有节点能接受写操作——不是你的代码或配置错了，而是协议层面的必然停顿。客户端发起 insertOne、updateOne 等写请求时，会收到类似 NotWritablePrimary 或 InterruptedDueToReplStateChange 的错误，而不是直接超时。
驱动超时设置不能绕过选举窗口，但能避免无限等待
很多开发者误以为调大 timeoutMS 就能“扛过”选举，其实恰恰相反：它会让客户端在选举完成前一直卡住，拖长整体响应时间。真正该做的是让驱动快速失败并交由业务逻辑处理重试或降级。
-
timeoutMS控制的是“整个操作生命周期”，包括选节点、拿连接、发命令、等响应——选举中主节点不存在，驱动会在超时后抛出ContextDeadlineExceeded（Go）或MongoTimeoutException（Java），而非等选举结束 - 写操作默认不自动重试（即使配置了
retryWrites=true），因为选举期间所有写都不可重试；只有成功连上新主后，后续请求才可能重试 - 建议将
timeoutMS设为 1000–3000 毫秒：短于典型选举耗时（通常
maxTimeMS 是查询层的保险丝，和选举无关
maxTimeMS 是发给服务器的指令，要求 mongod 在执行单个查询/聚合时主动中断，它不影响连接建立、节点选择或副本集状态判断。选举过程中，即使你加了 .maxTimeMS(5000)，写操作照样失败，因为根本没走到服务器执行阶段。
- 它只对已路由到可写节点的读/写命令生效；选举中无可用主节点，命令连发都发不出去
- 混淆
timeoutMS（客户端总耗时上限）和maxTimeMS（服务器端单命令执行上限）是高频误区 - 如果你在聚合里用了
$lookup或复杂索引扫描，再配maxTimeMS才有意义；单纯防选举，它不顶用
真正要检查的是 readPreference 和 writeConcern
有些应用在选举期仍希望读取从节点数据，却忘了显式设 readPreference=secondary；或者写操作用了强一致性 writeConcern={w: "majority"}，导致新主选出后还要等多数节点同步完才返回——这会放大延迟感知。
- 读场景：确认连接字符串或 client 配置里没硬编码
readPreference=primary，否则选举期所有读也全挂 - 写场景：
w: 1足够应对大多数业务；w: "majority"虽安全，但会显著延长写响应时间，尤其在跨地域副本集上 - Spring Boot 用户注意：
spring.data.mongodb.client-uri中的参数优先级高于代码配置，容易被timeoutMS写法覆盖却没生效
选举不是 bug，是 MongoDB 保证一致性的代价。驱动超时不是用来“撑过”它，而是帮你及时脱身——把阻塞变成可控错误，剩下的交给重试策略、降级开关或用户提示。别在 maxTimeMS 上浪费调试时间，先盯紧 timeoutMS 和 writeConcern 的组合效果。
