根本原因是MongoDB事务快照机制严格检测写冲突：只要两事务修改同一文档任意字段，后提交者即被中止并抛出WriteConflict；这是MVCC保证一致性所必需的代价。
为什么 MongoDB 事务在高并发更新同一行时总报 WriteConflict
根本原因不是锁粒度太粗，而是 MongoDB 的事务快照机制在写冲突检测上非常严格：只要两个事务尝试修改同一个文档的任意字段（哪怕只是 updatedAt 字段），后提交的那个就会被中止，抛出 WriteConflict 错误。这不是 bug，是 MVCC 下保证一致性必须付出的代价。
常见错误现象包括：WriteConflict 频繁出现、事务重试次数飙升、响应延迟毛刺明显、监控里看到大量 transactionRetries 指标跳涨。
- 典型场景：订单状态流转（多个服务/线程同时调用
updateOne更新同一订单）、库存扣减（抢购）、计数器累加（如点赞数） - 注意：即使你只读不写，只要事务内读了该文档，再有其他事务写它，也可能触发冲突 —— 因为读操作会绑定快照版本
- 性能影响显著：每多一次重试，就多一次网络往返 + 事务开销，实际吞吐可能跌到理论值的 1/5 以下
用 findAndModify 或 updateOne 替代事务更新单文档
如果目标只是“原子更新某一行”，压根不需要开启事务。MongoDB 原生的单文档写操作本身就是原子的，且不参与事务冲突链。
实操建议：
- 把逻辑从「启动事务 → 查询 → 修改 → 提交」改成直接用
updateOne带条件更新，例如：db.orders.updateOne({ _id: orderId, status: "pending" }, { $set: { status: "processing", updatedAt: new Date() } }) - 需要返回旧值？用
findOneAndUpdate，设returnDocument: "before"，它比事务内先findOne再updateOne更安全、更快 - 避免在事务里做纯单文档更新 —— 这等于主动把自己塞进冲突热点区
拆分热点文档：从「单行」到「多行聚合」
当业务确实绕不开“对同一逻辑实体高频写”，比如实时统计 PV、UV，硬扛冲突只会让问题更糟。正确思路是把写压力分散。
实操建议：
- 用分片键或哈希字段把一个逻辑计数器打散成多个物理文档，例如：
{ counterId: "page_views", shard: 0, value: 123 }、{ counterId: "page_views", shard: 1, value: 97 } - 写入时随机选一个
shard更新，读取时用$sum聚合所有分片；冲突概率下降为原来的1/N（N 是分片数） - 注意兼容性：应用层需封装读写逻辑，不能直接暴露分片细节；聚合查询要加索引（
{ counterId: 1, shard: 1 }）
事务重试策略不能只靠 try/catch 硬等
遇到 WriteConflict 就立即重试，容易引发雪崩：所有客户端在同一毫秒重试，下一轮冲突更密集。
实操建议：
- 必须实现退避重试（backoff），例如指数退避：
Math.pow(2, retryCount) + Math.random() * 100毫秒 - 设置最大重试次数（通常 3–5 次足够），超过就失败并记录日志，避免卡死或长尾请求
- 不要在事务内做耗时操作（如 HTTP 调用、文件读写），否则重试成本太高；把外部依赖移到事务外
真正棘手的地方往往不在代码怎么写，而在于没意识到「同一行」这个假设本身是否必要 —— 很多所谓“必须更新同一行”的需求，其实是建模时把聚合逻辑和存储耦合太紧了。
