先上结论：事务里的 writeConcern 只在 commitTransaction 那一刻才生效，内部那些 insert / update 操作传的参数？全被 MongoDB 当空气。想靠单条操作堆 w: "majority" 来兜底？门儿都没有。
事务中写关注只在 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 可以灵活设置，但优先级顺序必须理清楚：事务 > 集合 > 数据库 > 客户端全局。高优先级永远覆盖低优先级。
- 集合级设置最常见：Ja va 里用
collection.withWriteConcern(WriteConcern.MAJORITY)，Python 里用collection.with_write_concern(WriteConcern("majority"))。 - 客户端全局设置（比如 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 值只能砍掉复制等待的时间，但事务本身的串行化和锁竞争成本一样不少，该慢还是慢。
