生效，但仅作用于事务最终提交阶段；事务内各操作强制使用{w:1}，commitTransaction时指定的writeConcern才控制oplog确认级别，如{w:"majority",j:true}确保多数节点持久化。
WriteConcern 设置在 MongoDB 事务中是否生效？
生效，但仅作用于事务最终提交（commitTransaction）阶段，不作用于事务内各操作。事务内部的 insertOne、updateOne 等操作默认忽略传入的 writeConcern 参数，MongoDB 强制使用 { w: 1 } —— 即只写入主节点内存即返回，不等待复制或持久化。
真正起作用的是在 session.commitTransaction({ writeConcern: ... }) 中显式指定的 writeConcern。它控制的是「整个事务日志（oplog entry）被多少节点确认后，才认为事务成功提交」。
- 若省略
writeConcern，默认为{ w: "majority" }（副本集模式下），即多数节点确认后才返回成功 - 若设为
{ w: 1 }，只要主节点写入 oplog 就返回，延迟最低，但存在回滚风险（如主节点宕机且 oplog 未同步） -
{ w: "majority", j: true }表示多数节点不仅写入 oplog，还完成 journal 持久化，安全性最高，延迟也最明显
如何在事务中正确配置 writeConcern？
必须在调用 commitTransaction 时传入对象参数，不能通过客户端全局设置或在单条操作里指定：
session.startTransaction({ readConcern: { level: "snapshot" } });
collection.insertOne({ x: 1 }, { session });
collection.updateOne({ x: 1 }, { $set: { y: 2 } }, { session });
// ✅ 正确：writeConcern 只在这里生效
session.commitTransaction({
writeConcern: { w: "majority", j: true }
});
// ❌ 错误：以下写法对事务无影响
// collection.insertOne(..., { writeConcern: { w: 3 } }, { session });
// client.db().adminCommand({ setDefaultRWConcern: ... }); // 不影响事务
注意：writeConcern 的 w 值不能超过当前副本集的健康节点数；若设为 { w: 5 } 但只有 3 个可用节点，事务会卡住直至超时（默认 60 秒），抛出 WriteConcernFailed 错误。
为什么降低 writeConcern 仍可能遇到长延迟？
即使设为 { w: 1 }，事务提交延迟也不一定低——因为 MongoDB 事务还有两个隐式开销：
-
prepare 阶段阻塞：事务需先写入 prepare record 到 oplog，并等待所有参与分片（sharded cluster）或所有相关文档锁释放，这部分与
writeConcern无关 -
read concern snapshot 依赖：事务默认使用
snapshot级别，MongoDB 必须确保该快照点之前的所有 oplog 已被 majority 提交（即使你 commit 用w: 1），否则无法安全提供一致视图 -
journal 刷盘竞争：即使
j: false，WiredTiger 引擎仍可能因后台 flush 压力导致 prepare/commit 日志写入延迟升高
实测中，在高吞吐写入场景下，把 writeConcern 从 majority 降到 1，平均提交延迟下降约 30–50%，但 P99 延迟改善有限，瓶颈常转移到锁等待或存储引擎调度。
生产环境推荐的 writeConcern 组合
没有银弹，需按业务容忍度选：
-
金融类强一致性场景：用
{ w: "majority", j: true }，接受 50–200ms 级提交延迟，避免任何因主节点崩溃导致的已提交事务回滚 -
用户行为日志、非关键状态更新：可降为
{ w: 1 }，配合应用层幂等重试，延迟压到 10ms 内，但要接受极小概率的「已返回成功却丢失」 -
跨地域多数据中心部署：慎用
w: "majority"，因网络 RTT 波动大；建议改用{ w: "majority", wtimeout: 5000 }并捕获WriteConcernTimeout，主动降级为单节点写+异步补偿
真正容易被忽略的是：事务的 readConcern 和 writeConcern 是解耦的。你可以用 snapshot 读保证一致性，同时用 w: 1 提交来减延迟——但前提是能接受「读到的数据，其事务后续可能因写失败而回滚」这种罕见但合法的情况。
