选举期间写操作必然失败是正常现象，因无主节点导致notwritableprimary错误；应设serverselectiontimeoutms为1000–3000毫秒快速失败并由业务重试或降级，而非依赖retrywrites或延长超时。
选举期间写操作必然失败，这不是 bug，是 MongoDB 副本集协议的正常行为。 只要主节点（Primary）不可用，无论宕机、网络分区还是正在投票，所有写请求都会立即报 NotWritablePrimary 错误——不是你的代码没重试，也不是驱动配置错了，而是根本没人能收这个写请求。
rs.status() 显示 “NO PRIMARY” 时写操作为什么连发都发不出去
当 rs.status() 中看不到 stateStr: "PRIMARY"，说明副本集当前没有合法主节点。此时客户端驱动在发送写命令前，会先做节点选择（server selection），发现没有可写的节点，直接拒绝构造请求，抛出 NotWritablePrimary 或 Node is not in primary state。它甚至不会尝试连接任何节点，更不会把请求发到某个从节点上再被拒。
- 这个判断发生在客户端驱动层，不依赖网络 I/O，所以延迟极低（微秒级）
-
maxTimeMS在这种场景下完全不生效——它只控制“已发出去的命令在服务端执行多久”，而选举期间命令根本发不出去 - 如果你看到写请求卡住几秒才报错，大概率是驱动在反复轮询节点状态，而不是等服务端响应
timeoutMS 设太长反而会让业务更难恢复
客户端驱动的 timeoutMS（如 Node.js 驱动中的 socketTimeoutMS 或 connectTimeoutMS）控制的是底层 TCP 连接与读写等待时间。但选举期间真正该调的是 serverSelectionTimeoutMS 和 heartbeatFrequencyMS。
-
serverSelectionTimeoutMS默认 30 秒：驱动会在这段时间内不断检查副本集状态，直到找到主节点才发请求；设成 1000–3000 毫秒，能让业务快速感知“此刻不可写”，立刻走降级或重试逻辑 -
heartbeatFrequencyMS默认 10 秒：影响驱动刷新节点状态的频率；调小（如 2000）能更快发现新主，但会增加心跳流量 - 盲目加大
socketTimeoutMS到 30 秒，只会让每个写请求傻等，拖慢整体响应，掩盖真实故障窗口
retryWrites=true 对选举期间的写操作完全无效
retryWrites=true 仅对“已成功路由到主节点、但因临时错误（如 InterruptedAtShutdown、WriteConflict）失败”的写生效。选举期间根本选不到主节点，请求连路由这一步都过不去，retryWrites 压根不会触发。
- 你看到的重试日志，基本都是选举结束后、新主选出、后续请求自动重试的结果
- 真正需要你补全的是业务层重试：捕获
NotWritablePrimary后，sleep + retry，或切到本地缓存/消息队列暂存 - 如果用了
writeConcern: { w: "majority" }，即使选举完成，写也要等多数节点同步完才返回，这会进一步拉长用户感知延迟
最常被忽略的一点：选举本身不耗时，耗时的是业务没做好“无主”状态的兜底。驱动快速失败只是前提，能不能在 2 秒内把订单暂存到 Redis、把日志推到 Kafka、或给前端返回“稍后重试”，才是决定用户体验的关键。
