写入超时本质是 majority 条件不满足，非网络延迟所致，需检查副本集健康状态、votes 配置、journal 启用及事务 writeConcern 显式设置。
写入超时不是网络卡，而是 majority 条件不满足
“w: "majority" 写入超时”，通常不是连接慢或服务器忙，而是 MongoDB 服务端根本没收到足够多节点的确认——它在等一个永远等不到的多数应答。驱动层 timeoutMS 触发前，服务端已判定写入无法满足 write concern，直接返回 WriteConcernMajorityNotSatisfied 或卡在 commit 阶段。这种错误和网络延迟无关，本质是副本集健康状态或配置问题。
- 检查
rs.status()中每个成员的health（必须为1）、state（2表示正常 secondary）、votes（必须为1）；votes: 0的节点不参与 majority 计算，但会拉低实际 majority 数值 - 确认所有 voting 节点都开启了 journal：
storage.journal.enabled: true；否则即使写入了多数节点，也会因未持久化而被服务端拒绝计入 majority - 运行聚合查询快速定位拖后腿的节点：
db.adminCommand({ replSetGetStatus: 1 }).members.filter(m => m.health !== 1 || m.state !== 2 || m.votes !== 1)
事务里 w: "majority" 失败更隐蔽，必须显式传参
事务默认不继承客户端全局 writeConcern，session.startTransaction() 必须显式带 writeConcern 参数，漏设会导致事务内写操作用默认 w: 1，但 commit 时又强制校验 majority，直接报错 "Cannot specify write concern in both transaction options and operation"。
- 正确写法：
session.startTransaction({ writeConcern: { w: "majority", j: true, wtimeout: 5000 } }) -
j: true不可省略——它要求 journal 持久化完成才算确认，否则即使节点在线、有投票权，也不计入 majority -
wtimeout: 5000是服务端等待多数确认的上限（毫秒），设太小容易误判失败，太大则掩盖真实健康问题；建议从3000起调，结合监控观察失败节点分布
别信 rs.status() 显示的 PRIMARY，要查 optimes 和 votes 配置
网络分区后，少数派子集可能选出自己的 PRIMARY，rs.status() 在各自视角下都显示 "stateStr": "PRIMARY"，但只有多数派那个能真正处理 w: "majority"。你连上的可能是“假主”，它拒绝写入并返回 NotMaster 或 InterruptedDueToReplStateChange。
- 在疑似 PRIMARY 上执行：
db.runCommand({ replSetGetStatus: 1 })，比对各成员的optimes.lastCommittedOpTime；差距超过几秒的，基本就是被隔离的假主 - 检查
rs.conf()中每个成员的votes字段：严禁出现"votes": 2或非整数；总 votes 数必须为奇数且 ≥3，否则选举逻辑异常 - 应用层不要轮询连接所有种子节点，应在每次写前轻量探测：
db.runCommand({ isMaster: 1 })，检查返回中ismaster为true且hosts数量与预期一致（如应有 3 个 host，却只返回 1 个，说明已被隔离）
驱动层 timeoutMS 设太长反而掩盖问题
把 timeoutMS 从默认 30000 改成 60000，并不能“扛过” majority 不满足的状态——服务端不会等，它立刻拒绝。长超时只会让应用线程卡住更久，掩盖副本集真实故障点。
- 写操作建议设
timeoutMS: 3000：短于典型选举耗时（通常 - 不要混淆
timeoutMS（客户端总生命周期）和maxTimeMS（服务端单命令执行上限）；后者对 majority 不满足完全无效，因为请求根本没发到服务端执行阶段 - 启用
retryWrites=true对 majority 超时无效——可重试写入只针对临时性错误（如 NotMaster 切换瞬间），不重试WriteConcernMajorityNotSatisfied这类永久性配置/健康问题
多数派节点 journal 关闭、隐藏节点意外参与投票、votes 配置错位——这些细节不报错，但会让 w: "majority" 在看似正常的集群里突然失效。排查必须下沉到配置项和 oplog 时间戳，不能只看表面状态。
