UnknownTransactionCommitResult错误本质是服务端无法确认事务是否提交成功，必须重试整个事务体而非仅commitTransaction；需新建session、设snapshot读关注、确保所有写操作幂等。
这是 MongoDB 服务端明确告知“我也不知道事务到底成没成”，不是网络丢包，也不是客户端 bug，必须按幂等逻辑重试整个事务体
UnknownTransactionCommitResult 错误的本质
客户端调用 commitTransaction() 后没收到成功或失败的明确响应，服务端返回 UnknownTransactionCommitResult。这不是超时重试失败，而是服务端自己也失去了对事务最终状态的掌控——可能已提交、可能被丢弃、也可能卡在 prepare 阶段。常见诱因包括主节点切换瞬间、网络分区导致 commit 请求发出后连接断开、或仲裁节点投票未达成 majority。
此时驱动（PyMongo / Node.js / Rust）不会自动重试，with_transaction() 也不捕获它，因为它的语义和 TransientTransactionError 不同：后者是“可恢复的临时失败”，而前者是“结果不可知”。
为什么不能只重试 commitTransaction()
重试 commitTransaction() 会立刻报 NoSuchTransaction 或 TransactionTooOld，因为事务上下文（txnNumber）在服务端已失效或被清理。你手里的 session 已不可用。
- 必须先调用
session.endSession()，防止连接池中残留无效 session - 新建
ClientSession，再显式调用session.startTransaction() - 读操作必须加
readConcern: "snapshot"，否则两次事务重试可能读到不一致快照 - 所有写操作必须幂等：用
updateOne({ _id }, { $setOnInsert: {...} }, { upsert: true })替代insertOne()；用带条件的$set替代无保护覆盖
哪些错误该重试，哪些不该碰
不是所有事务错误都适合重试。生产环境必须区分语义：
- 应重试：
TransientTransactionError（可用error.hasErrorLabel("TransientTransactionError")判断）、UnknownTransactionCommitResult、WriteConflict（error.code === 112） - 不可重试：
InvalidNamespace、Unauthorized、DocumentValidationFailure——这些是代码或配置错误，重试只会重复失败
注意：WriteConflict 在 MongoDB 4.2+ 中不再自动带 TransientTransactionError 标签，必须单独检查 error.code。
底层配置不匹配会让重试失效
即使代码完全正确，以下配置缺失或不一致，也会让 UnknownTransactionCommitResult 高频出现且重试无效：
- 所有副本集/分片成员必须启用
enableMajorityReadConcern=true，否则 prepare 阶段静默失败 - 各分片 MongoDB 小版本号（含补丁号，如
6.0.12vs6.0.15）必须完全一致，gitVersion也须相同 -
writeConcern必须设为{ w: "majority", j: true }；w: 1几乎必然触发该错误 - 副本集投票节点数必须为奇数且 ≥3，否则
"majority"语义失效
最容易被忽略的是：分片集群中，w: "majority" 是按每个分片副本集内部单独计算的——某个分片的 secondary 全挂，该分片就无法满足 majority，整个跨分片事务直接失败。
