w: 1 在事务中导致 oplog 覆盖风险，是因为它仅保证主节点写入即返回，不等待从节点同步，当 secondary 拉取速度慢于主节点写入速度时，固定大小的 oplog（如 5GB）中旧记录被覆盖，若 oldestTimestamp 落后超保留窗口（如 40 分钟 > 30 分钟），同步中断触发 initial sync；w: "majority" 并非降低性能，而是提前暴露同步失败，确保多数节点落盘后再提交，且 writeConcern 仅在 session.commitTransaction({ writeConcern: ... }) 时生效，其他位置设置无效；w: 0 极其危险，可能造成日志未刷盘即丢失，生产环境严禁使用，必须配 wtimeout 防止事务卡死。
为什么 w: 1 在事务中会导致 oplog 覆盖风险
不是“写没落盘”，而是 secondary 同步跟不上时，oplog.rs 被新日志覆盖，导致从节点无法追上主节点，最终触发 initial sync 或同步中断。事务提交快 ≠ 数据安全，w: 1 只保证 primary 写完就返回，不校验 secondary 是否已复制。
- oplog 是固定大小的循环日志（默认 5GB），secondary 拉取速度慢于主节点写入速度时，旧 oplog 条目会被覆盖
- 事务产生的多条 oplog 记录（如
updateMany匹配 1000 条，生成 1000 条 oplog）会密集写入 oplog，加速覆盖进程 - 一旦 secondary 的
oldestTimestamp落后超过 oplog 保留窗口（比如落后 40 分钟，而 oplog 只存 30 分钟数据），同步链路断裂
w: "majority" 不是性能杀手，而是故障面控制手段
设 w: "majority" 看似拖慢事务，实则是把“潜在同步失败”提前暴露为显式错误，而不是让它在后台静默腐烂。它不会增加 oplog 总量，只改变确认时机。
- 事务提交前，所有 oplog 条目已在内存构造完毕；
w: "majority"只决定“等多数节点落盘后再返回”，不改变写多少条 - 若副本集只有 3 个健康节点，
w: "majority"等效于w: 2；设成w: 5会卡住直到超时（默认 60 秒），报WriteConcernFailed - 配合
db.getReplicationInfo()监控oldestTimestamp，比看timeDiffHours更准——后者可能掩盖已断连但未上报的状态
ORM 层（如 Mongoose）容易偷偷覆盖 writeConcern
很多框架在连接初始化时全局设了 writeConcern: { w: 1 }，但事务 commit 时传参不生效，导致你以为用了 w: "majority"，实际还是 w: 1。
-
session.commitTransaction({ writeConcern: { w: "majority" } })是唯一生效位置；在insertOne或updateOne调用里传writeConcern参数无效 - Mongoose 的
Model.insertMany(..., { writeConcern: ... })也不影响事务内行为，事务 writeConcern 必须在commitTransaction时指定 - 检查你是否调用了
client.db().adminCommand({ setDefaultRWConcern: ... })——它对事务完全无影响，纯属干扰项
真正危险的是 w: 0 和未设 wtimeout
w: 0 不仅跳过 write concern 校验，还会让 oplog 写入变成“fire-and-forget”，主节点 crash 后这部分事务日志可能从未刷盘，数据彻底丢失。
- 生产环境禁止使用
w: 0；哪怕w: "majority"带来 100ms 延迟，也远小于一次 initial sync 的分钟级中断 - 必须配
wtimeout: 5000（单位毫秒），否则网络抖动或单节点临时失联会让事务卡满transactionLifetimeLimitSeconds（默认 60 秒），然后被强制中止 - 事务中所有写操作共享同一份 oplog 上下文，
wtimeout是针对整个事务提交动作，不是单条命令
commitTransaction 这一刻起作用，且必须匹配当前副本集真实健康节点数。其他任何地方设的，都是摆设。 
