事务冲突本质是写操作竞争同一文档导致的提交失败，readconcern仅控制读可见性，不干预写冲突判定；需通过拆分热点文档、使用原子操作、幂等重试等策略应对。
事务冲突不是靠调高 ReadConcern 就能解决的，它本质是写操作竞争同一文档导致的提交失败，ReadConcern 只影响读可见性，不干预写冲突判定。
为什么 setReadConcern("majority") 无法避免写冲突
常见误解是把 readConcern 当成“锁升级开关”——比如认为设成 "majority" 就能让事务更“稳”。但实际机制完全不同：readConcern 控制的是“读到什么版本的数据”，而写冲突发生在 commitTransaction() 阶段，由 WiredTiger 的 MVCC 版本校验触发。即使你用 readConcern: { level: "majority" }，两个并发事务仍可能同时读到旧版本、各自修改、最终在提交时发现对方已抢先写入，触发 WriteConflict 错误。
关键点：
-
readConcern不改变事务内写操作的加锁/校验逻辑 - 它只影响
find()、count()等读命令返回的内容（比如是否看到未提交数据、是否等待多数节点确认） - 对
insertOne、updateOne这类写操作本身无直接影响
真正有效的写冲突应对策略
写冲突（WriteConflict）必须从“减少竞争面”和“优雅重试”两头入手：
- 拆分热点文档：把高频更新的字段（如计数器、状态戳）从大文档中剥离，单独存为独立文档，避免多个事务争抢同一
_id - 使用
findAndModify替代先查后改：原子操作天然规避中间态竞争，比如库存扣减直接用updateOne({ _id: id }, { $inc: { stock: -1 } }, { upsert: false }) - 客户端必须实现幂等重试：捕获
WriteConflict错误后，重建 session 并重放整个事务逻辑（不能只重试最后一条语句） - 避免长事务：60 秒默认超时不是摆设，事务越长，与其他操作重叠概率越高；业务上尽量压缩事务内操作步骤
ReadConcern 在事务中的实际作用边界
它只在事务内读操作生效，且仅决定“读一致性级别”，与冲突无关：
-
readConcern: { level: "local" }（默认）：读取当前节点最新已应用 oplog 的数据，可能读到之后被回滚的内容 -
readConcern: { level: "majority" }：确保读到已被大多数节点确认的数据，适合需要强一致读的场景（如订单创建后立刻查状态），但会增加延迟 -
readConcern: { level: "snapshot" }：事务内所有读都基于同一快照，保证事务内读一致性，但不防止写冲突
注意：writeConcern 才影响写持久性保障，比如 w: "majority" 要求多数节点落盘才返回成功，但它也不参与冲突检测逻辑。
验证写冲突是否真实发生
别只看日志里有没有报错，要主动检查：
- 连接后执行
db.currentOp({ "secs_running": { "$gt": 5 } })，看是否有长时间卡在"waitingForLock"或"awaitingFlowControl"的操作 - 监控指标
globalLock.lockTime和metrics.record.moves异常升高，往往是写冲突频发的间接信号 - 驱动层捕获异常时，打印完整错误堆栈，确认是否为
WriteConflict类型（不是DuplicateKey或NotMaster）
最易被忽略的一点：事务内混用非事务操作（比如在 session.startTransaction() 后，又调用未绑定 session 的 db.collection.insertOne()），会导致部分操作脱离事务上下文，看似成功实则破坏原子性——这种“伪成功”比明确报错更危险。
