UnknownTransactionCommitResult错误必须重试整个事务体而非仅commitTransaction，因服务端状态未知，重试commit会触发NoSuchTransaction；需新建session、设snapshot读关注、写操作幂等。
UnknownTransactionCommitResult 必须重试整个事务体，不能只重试 commitTransaction()
这个错误不是网络超时，而是服务端无法确认事务是否已提交——它可能成功了，也可能失败了。此时 session 状态已失效，再调用 commitTransaction() 会直接抛 NoSuchTransaction 或 TransactionTooOld。
常见错误现象：日志里反复出现 UnknownTransactionCommitResult，但业务数据时而重复、时而丢失；手动重试 commitTransaction() 后报错 InvalidSession。
- 每次重试前必须调用
session.endSession()，否则连接池中残留 session 可能泄漏 - 必须新建
ClientSession，并显式调用session.startTransaction() - 事务内所有读操作要加
readConcern: "snapshot"，否则两次重试可能看到不同快照 - 写操作全部改为幂等形式：用
updateOne({ _id }, { $setOnInsert: {...}, $set: {...} }, { upsert: true })替代insertOne()；用带条件的updateOne(..., { $inc: { balance: -100 } }, { ... })替代无保护的数值变更
哪些错误该重试，哪些绝对不该
不是所有事务失败都适合重试。盲目重试语义错误只会让问题更难排查。
- 应重试：
TransientTransactionError（可用error.hasErrorLabel("TransientTransactionError")判断）、UnknownTransactionCommitResult、WriteConflict（error.code === 112，注意 MongoDB 4.2+ 不再自动打标签） - 不可重试：
InvalidNamespace、Unauthorized、DocumentValidationFailure、DuplicateKey（除非你明确设计为幂等冲突处理） - 特别注意：
TransactionTooLargeForCache（MongoDB 6.2+）和upsert在事务中遇到重复键（MongoDB 8.1+）都不再自动重试，代码里必须提前拦截或降级处理
底层配置不匹配，代码写得再对也高频触发错误
很多团队花几天调试重试逻辑，最后发现是部署层配置没对齐。这些设置一旦出错，UnknownTransactionCommitResult 出现频率会陡增。
- 所有副本集/分片节点必须启用
enableMajorityReadConcern=true，否则 prepare 阶段静默失败 - 各分片 MongoDB 小版本号（含补丁号，如
6.0.12vs6.0.15）和gitVersion必须完全一致 -
writeConcern必须设为{ w: "majority", j: true }；w: 1几乎必然导致该错误 - 副本集投票节点数必须为奇数且 ≥3，否则
"majority"语义失效，事务无法完成两阶段提交
手写重试循环比 with_transaction() 更可控
with_transaction() 默认只重试提交阶段，最多 5 次、无退避、不支持自定义错误判断——生产环境基本不够用。
- 把整个事务逻辑封装成纯函数（如
transfer_money(session, from_id, to_id, amount)），不依赖外部状态 - 外层用指数退避循环，例如第 1 次等待 100ms，第 2 次 200ms，第 3 次 400ms
- 每次循环都新建
ClientSession，并在try块开头就startTransaction() - 避免在事务中调用 HTTP 接口或读取本地缓存——重试时这些外部依赖可能已变，破坏幂等性
真正容易被忽略的点是：事务内读取结果不能复用。哪怕上一次读到了 { balance: 500 }，重试时必须重新查一遍——因为中间可能已被其他事务扣减。
