MongoDB副本集选举期间writeConcern超时而非降级，因其默认坚持一致性优先契约，w:"majority"写操作在主节点失联且新主未选出时直接阻塞或报WriteConcernFailed。
为什么 MongoDB 副本集选举期间 writeConcern 会超时而不是降级？
因为默认写操作不设容错兜底逻辑，mongod 在主节点失联、新主未选出前，所有带 w: "majority" 的写请求直接阻塞或报 WriteConcernFailed，应用层若没捕获就崩。这不是 MongoDB 的 bug，是它把“一致性优先”当默认契约。
- 真实场景：电商秒杀下单时副本集刚好触发选举，5–12 秒空窗期里大量
insertOne报MongoWriteConcernException - 关键参数差异：
w: 1可立即返回（只写原主），但主挂了就失败；w: "majority"安全但卡死；w: "majority"+j: true更卡 - 别指望驱动自动降级——Java Driver、PyMongo、Node.js MongoDB Driver 都不会把
w: "majority"自动 fallback 成w: 1
怎么让应用在选举空窗期自动切到 w: 1 写入？
靠重试策略 + 状态感知，不是靠改配置。MongoDB 本身不提供“选举中临时降级”的开关，得自己判断并换写法。
- 监听
topologyDescriptionChanged事件（Node.js）或ClusterListener（Java），检测type: "ReplicaSetNoPrimary"状态出现 - 维护一个内存标记
isInElectionWindow，置为true后，后续写操作改用writeConcern: { w: 1 } - 不要等超时才降级：设置
serverSelectionTimeoutMS: 500和socketTimeoutMS: 1000，比默认快，更快触发降级入口 - 示例（Node.js）：
collection.insertOne(doc, { writeConcern: isInElectionWindow ? { w: 1 } : { w: "majority" } })
MongoNetworkError 和 MongoNotConnectedError 哪些该重试、哪些该降级？
错误类型决定响应动作。盲目重试会让空窗期更长，盲目降级又可能丢数据。
-
MongoNetworkError：网络抖动引起，可立即重试 1–2 次（加maxStalenessSeconds避免读到旧数据） -
MongoNotConnectedError/MongoServerSelectionError：说明 driver 连不上任何节点，大概率在选举中，此时应进入降级流程，而非重试 -
MongoWriteConcernException中的"not master"或"node is recovering"子消息，是明确信号，立刻切w: 1并记录告警 - 注意：PyMongo 的
AutoReconnect已废弃，新版用ConnectionFailure，必须显式处理
降级写入后，怎么避免数据不一致被业务感知？
降级不是免责，只是把“失败”换成“尽力而为”，业务层得补上语义校验和补偿路径。
- 所有
w: 1写入必须带唯一业务 ID（如order_id），后续用findOne主动查确认是否落库 - 写入降级时，同步发消息到 Kafka/RabbitMQ，由异步服务轮询 MongoDB 补单或告警人工介入
- 禁止在降级模式下执行依赖强一致的事务：
session.startTransaction()必须在isInElectionWindow === false时才允许调用 - 监控重点不是“有没有降级”，而是“降级后
findOne查不到的比例”——这才是真实数据风险点
isMaster 命令返回 ismaster: true 也不代表新主已同步完 oplog。得结合心跳间隔、lastWriteDate 时间戳交叉验证，否则容易过早切回 w: "majority" 导致二次失败。 
