事务中writeconcern仅在committransaction时生效，内部insert/update操作强制使用{w:1}且忽略传入参数；commit时指定{w:"majority",j:true}可确保多数节点持久化，但w值不可超过健康节点数。
事务中写关注只在 commitTransaction 时生效，单条操作传 writeConcern 参数完全无效。
事务内 insert/update 操作不支持 writeConcern
很多人误以为给 insertOne 或 updateOne 传 { writeConcern: { w: "majority" } } 就能提升事务安全性——实际会被 MongoDB 忽略。事务内部所有写操作强制使用 { w: 1 }，即仅主节点内存写入就返回，不等待复制或 journal。
- 这是硬编码行为，无法绕过，也不受客户端默认设置影响
- 即使你在
collection.insertOne(..., { writeConcern: { w: 3 } })里写了，MongoDB 也会静默丢弃该参数 - 真正控制安全边界的，只有
session.commitTransaction({ writeConcern: ... })这一处
commitTransaction 的 writeConcern 决定最终一致性
commitTransaction 的 writeConcern 控制的是整个事务 oplog entry 被多少节点确认后才返回成功。它不决定单步执行是否落盘，而是决定“这个事务是否被集群认为已提交”。
-
{ w: "majority" }（默认）：多数有投票权节点写入 oplog 后即返回；适合大多数业务场景 -
{ w: "majority", j: true }：多数节点不仅写入 oplog，还完成 journal 持久化；抗宕机能力最强，但延迟明显上升 -
{ w: 1 }：仅主节点写入 oplog 就返回；延迟最低，但主节点崩溃未同步时事务可能回滚 -
w值不能超过当前健康节点数，比如设{ w: 5 }但只有 3 个可用节点，事务会卡住直到超时（默认 60 秒），抛出WriteConcernFailed错误
非事务写操作的 writeConcern 配置位置
普通 CRUD（非事务）可灵活设置 writeConcern，但优先级顺序必须清楚：事务 > 集合 > 数据库 > 客户端全局。高优先级设置会覆盖低优先级。
- 集合级最常用：
collection.withWriteConcern(WriteConcern.MAJORITY)（Java）或collection.with_write_concern(WriteConcern("majority"))（Python） - 客户端全局设置（如 C# 的
MongoClientSettings.WriteConcern）只影响未显式覆盖的操作 - Shell 中可用
db.getMongo().setWriteConcern({ w: 2, wtimeout: 1000 })，但注意它只对后续命令生效，不回溯 - 避免混用：比如在事务外用
{ w: 1 }提升吞吐，事务内却依赖{ w: "majority", j: true }保底，这种组合是合理且常见的
容易被忽略的隐式开销
即使把 commitTransaction 的 writeConcern 设为 { w: 1 }，事务延迟也不一定低——因为 MongoDB 还有两个隐藏成本：
- 事务日志（oplog entry）必须先序列化、加锁、写入主节点的 oplog collection，这本身就有开销
- 所有参与事务的文档必须先获取两阶段锁（2PL），锁持有时间随操作复杂度线性增长
- 如果事务跨多个分片，协调节点还要额外等待各分片 prepare 和 commit 的 RPC 往返
所以，单纯调低 w 值只能减少复制等待，不能消除事务本身的串行化和锁竞争成本。
