writeconcern超时在事务中更致命，是因为事务的writeconcern仅在commit_transaction()瞬间统一校验，一旦副本集无法满足w:"majority"等要求（如secondary不可用、journal卡住或votes异常），即抛writeconcernfailed错误并强制回滚全部操作，而非仅延迟。
为什么WriteConcern超时在事务里更致命
事务提交时的 WriteConcern 超时不是“慢一点”，而是直接失败——commitTransaction() 会抛出 WriteConcernFailed 或 WriteConcernMajorityNotSatisfied，整个事务回滚，之前所有操作白做。这不是网络延迟导致的临时卡顿，而是副本集已无法满足你声明的写入安全级别。
根本原因在于：事务的 writeConcern 只在 commit_transaction() 一瞬间统一校验，所有写操作都绑定在同一组节点确认要求上。只要有一个 secondary 不可用、journal 写入卡住、或 votes 配置异常，整个 commit 就崩。
- 默认不继承客户端全局
writeConcern，漏设session.startTransaction({ writeConcern: ... })会导致用w: 1，但后续操作若显式传writeConcern，会报错"Cannot specify write concern in both transaction options and operation" - 分片集群中，
w: "majority"是按每个 shard 的副本集单独算 majority，一个 shard 的 secondary 全挂，该 shard 就过不了关 -
wtimeout单位是毫秒，且必须设在startTransaction里，不能只靠连接串里的wtimeoutMS
如何正确设置事务 writeConcern 参数
必须显式传入 session.startTransaction()，不能依赖默认，也不能分散设置。
推荐配置（生产环境）：
session.startTransaction({
writeConcern: {
w: "majority",
j: true,
wtimeout: 5000
}
})
-
w: "majority"是底线，w: 1在主从切换时可能丢数据；w: 0禁止用于事务 -
j: true强制 journal 持久化，避免 crash 后丢失已确认写入 -
wtimeout: 5000—— 不要设成 0（无限等待），也不要超过 10000（多数场景下 >5s 已说明副本集健康度出问题） - 不要在单个操作（如
update_one()）里再传writeConcern，否则和事务级冲突
快速判断哪个节点拖垮 majority
别只看 rs.status().members[n].stateStr === "SECONDARY"，那只是进程活着。真正影响 w: "majority" 的是投票权 + 心跳 + journal 能力。
在 primary 上运行这个检查（注意时间戳是当前）：
db.adminCommand({ "replSetGetStatus": 1 }).members
.filter(m => m.health !== 1 || m.state !== 2 || m.votes !== 1 ||
(Date.now() - new Date(m.lastHeartbeatRecv).getTime()) > 10000)
.map(m => ({ name: m.name, state: m.state, health: m.health, votes: m.votes, lastHeartbeatRecv: m.lastHeartbeatRecv }))
-
health: 0→ 完全不可达（防火墙、mongod 崩溃） -
state: 8（DOWN）或10（ROLLBACK）→ 已被踢出同步源，不参与 majority -
votes: 0→ 隐藏节点/延迟节点，不计入 majority 计算，但会拉低实际 majority 值（例如 5 节点中 2 个votes: 0，则 majority = 2，不是 3） -
lastHeartbeatRecv超过 10 秒 → 主节点已将其标记为失联，不会等它
max_commit_time_ms 和 wtimeout 的区别与误用
max_commit_time_ms 是 commit 阶段的服务端逻辑超时，wtimeout 是 writeConcern 等待多数节点响应的超时，二者完全独立、不可替代。
-
wtimeout控制“等多数节点落盘最多花多久”，超时即失败，返回WriteConcernFailed -
max_commit_time_ms控制“commit 这个动作本身最多执行多久”，超时返回MaxTimeMSExpired，仅对commit_transaction()生效 - 设了
max_commit_time_ms=30000但没设wtimeout，仍可能因 secondary 长期无响应，在 commit 前就卡死 - 两者都设了，但
max_commit_time_ms大于服务端transactionLifetimeLimitSeconds（默认 60 秒），事务早被 kill，commit 请求发出去也会收到ConnectionFailure
真正容易被忽略的是：wtimeout 不是“整个事务生命周期”，它只管 commit 那一刻的多数确认。如果 majority 本身已残缺，再调大 timeout 也没用——得先修节点，而不是调参数。
