TransientTransactionError、UnknownTransactionCommitResult 和 WriteConflict（code 112）应重试，而 InvalidNamespace 等语义错误不可重试；建议外层控制 2～3 次指数退避重试，并结合幂等设计与业务约束保障正确性。
事务失败时 TransientTransactionError 到底该不该重试？
不是所有事务错误都适合重试。MongoDB 明确将 TransientTransactionError 标记为“可重试的瞬态错误”，比如网络抖动、主节点切换、临时锁冲突；而 UnknownTransactionCommitResult 表示提交结果未知，WriteConflict 通常由高并发写入引发——这两类也应纳入重试范围。但 InvalidNamespace、Unauthorized 或 DocumentValidationFailure 这类语义错误，重试只会重复失败。
实操建议：
- 捕获异常后，用
error.hasErrorLabel("TransientTransactionError")或error.hasErrorLabel("UnknownTransactionCommitResult")判断是否进入重试逻辑 - 避免在事务回调函数（如
session.withTransaction()的执行体）内直接重试，应由外层控制重试次数和退避策略 - 注意：4.2+ 版本中，
WriteConflict不再自动带TransientTransactionError标签，需显式检查error.code === 112
重试次数设为 3 次合理吗？
3 是常见经验值，但不是银弹。实际要结合业务 SLA 和底层集群响应特征调整。短事务（毫秒级）在多数场景下 2～3 次足够覆盖一次主从切换窗口；长事务（秒级）若重试 3 次，可能累积超时风险，反而放大雪崩效应。
实操建议：
- 初始重试上限设为
maxRetries = 3，但必须配合指数退避（如 100ms → 300ms → 900ms），避免重试风暴 - 对读多写少、最终一致性可接受的场景，可降级为“最多重试 1 次 + 异步补偿”，而非强等事务成功
- 监控
transaction.abortCount和重试耗时分布，若 95% 重试在第 2 次成功，说明第 3 次大概率冗余
withTransaction() 的 readConcern 和 writeConcern 怎么配才不拖慢重试？
默认 readConcern: "local" 和 writeConcern: { w: "majority" } 能保证事务安全，但 w: "majority" 在副本集同步延迟高时会显著拉长事务生命周期，增加锁持有时间和重试概率。
实操建议：
- 核心资金类操作保留
writeConcern: { w: "majority" }；日志、统计类事务可降级为{ w: 1 }，牺牲一点持久性换取更低冲突率 - 避免在事务中使用
readConcern: "snapshot"（仅分片集群支持），它会强制获取全局快照时间戳，加重协调器压力 - 若应用已部署在 MongoDB 6.0+ 且开启 causal consistency，可用
afterClusterTime替代部分readConcern: "majority"场景，减少等待
重试时如何防止重复扣款或重复下单？
重试本身不解决幂等性问题——它只是让失败的事务有机会再跑一次。如果事务体里有 updateOne({ orderId }, { $inc: { amount: -100 } }) 这种无条件更新，重试三次就扣三次。
实操建议：
- 所有写操作必须带业务唯一约束，例如扣款前先查
status: "pending"，再用updateOne({ orderId, status: "pending" }, { $set: { status: "done" }, $inc: { balance: -100 } }) - 在事务外生成带时间戳的请求 ID（如
reqId = uuid() + "-" + Date.now()），写入时存入requestId字段，并建唯一索引，拦截重复提交 - 慎用
$push类操作，重试会导致数组重复追加；改用$addToSet或先$pull再$push
事务重试不是兜底开关，它把分布式系统的不确定性显式暴露给了业务代码。真正难的不是写个 for 循环调 withTransaction()，而是厘清哪类失败能靠重试掩盖，哪类必须靠状态机+补偿+人工介入来终结。
