unknowntransactioncommitresult表示提交结果未知而非失败，主因是网络中断、主节点宕机或超时导致响应丢失；须重试整个事务体而非仅commit，且读操作必须用readconcern: "snapshot"并确保幂等。
UnknownTransactionCommitResult不是提交失败，而是结果未知
这个错误不表示数据没写进去，也不代表事务被回滚了——它只说明客户端发出了 commitTransaction 请求，但没收到服务端的明确响应。常见诱因包括：主节点在 majority 写入完成前宕机、SLB/Nginx 主动断开长连接、网络分区导致响应包丢失、或事务已超时被服务端静默 abort。此时服务端真实状态是未知的，你不能假设“没成功”就重试 commit，也不能直接认为“已成功”就往下走。
别 retry commitTransaction()，要重试整个事务体
直接对同一个 ClientSession 再调一次 commitTransaction() 会报 NoSuchTransaction 或 TransactionTooOld，因为事务上下文（txnNumber）在服务端已被清理或失效。正确做法是：
-
session.endSession()显式释放当前 session - 新建一个
ClientSession - 调用
session.startTransaction()重新开启事务 - 重放所有读写操作（注意：必须幂等）
- 再执行
commitTransaction()
尤其要注意：读操作必须带 readConcern: "snapshot"，否则两次重试可能读到不同快照，导致逻辑错乱。
驱动 API 选择直接影响重试逻辑是否自动生效
不同 API 层级处理 UnknownTransactionCommitResult 的方式差异极大：
- 回调式 API（如 Node.js 的
session.withTransaction()、Go 的UseSessionWithOptions）：默认包含对UnknownTransactionCommitResult的提交重试逻辑，但仅重试 commit 动作本身，不重放业务逻辑 - 核心 API（显式调用
startTransaction/commitTransaction）：完全不处理该错误，需你手动捕获error.hasErrorLabel("UnknownTransactionCommitResult")并触发完整事务重试 - MongoDB 6.2+：遇到
TransactionTooLargeForCache错误时，服务端不再允许重试，需提前控制事务内操作数量和文档大小
最容易漏掉的三个配置项，会让重试彻底失效
90% 的 UnknownTransactionCommitResult 根源不在代码，而在服务端或驱动配置不匹配：
-
transactionLifetimeLimitSeconds默认 60 秒，在跨 AZ 或专线高延迟场景下极易超时；建议设为180 -
heartbeatFrequencyMS默认 10000，但 RTT > 80ms 时应调至2000，否则心跳失准会导致驱动误判节点失联，进而中断事务 - 所有副本集成员必须启用
enableMajorityReadConcern=true，否则 prepare 阶段静默失败，后续 commit 必然返回未知结果
这些配置改完后必须重启 mongod 进程才生效，热加载不支持。
