Commit failed 表示服务端无法确认提交是否成功，而非事务失败；可能因主节点宕机、网络分区、连接中断或超时导致，需检查配置、重试整个事务体并确保读写一致性。
Commit failed 的真实含义不是“提交失败”，而是“服务端无法确认是否提交成功”
这个错误本身不说明事务没执行，也不代表数据丢了——它只表示客户端发出了 commitTransaction 请求，但没收到明确响应。可能的情况包括：主节点在写入 majority 节点前宕机、网络分区导致响应丢失、客户端连接被 SLB/Nginx 主动断开、或事务已超时被服务端静默 abort。此时服务端状态未知，你看到的 UnknownTransactionCommitResult 或 context deadline exceeded 都是这一现象的表层报错。
先查服务端配置，再看代码逻辑
90% 的 Commit failed 根源不在应用代码，而在底层配置不匹配：
-
transactionLifetimeLimitSeconds默认 60 秒，在跨 AZ 或专线场景下（RTT > 80ms）极易触发超时；建议设为180（单位秒） -
heartbeatFrequencyMS默认 10000，但高延迟网络下应调至2000，否则心跳失准会导致驱动误判节点失联 - 所有副本集成员必须启用
enableMajorityReadConcern=true，否则 prepare 阶段会静默失败 -
writeConcern必须显式设为{ w: "majority", j: true }；w: 1几乎必然导致不确定状态 - 分片集群中，各 shard 的
logicalSessionCacheRefreshPeriodMS建议从默认300000改为30000，避免事务号不同步
重试不能只 retry commitTransaction()
直接重试 commitTransaction() 会报 NoSuchTransaction 或 TransactionTooOld，因为事务上下文（txnNumber）已在服务端失效或清理。正确做法是重试整个事务体：
- 立即调用
session.endSession()，防止 session 泄漏 - 新建
ClientSession，显式调用session.startTransaction() - 读操作必须加
readConcern: "snapshot"，否则两次读可能看到不一致快照 - 写操作全部改为幂等形式：
updateOne({ _id }, { $setOnInsert: {...} }, { upsert: true })替代insertOne()；用条件更新替代无保护写入 - 仅对
error.errorLabels?.includes('TransientTransactionError')或error.code === 112（写冲突/会话过期）重试；Unauthorized、DocumentValidationFailure等语义错误不可重试
最容易被忽略的三个实操细节
它们不报错，但会让事务“看似成功实则无效”：
- 事务内读操作没加
readConcern: "snapshot"—— 导致读已提交（read committed）而非快照隔离，后续写可能基于脏读 - 把
ClientSession存在 request context 外（如静态变量、全局缓存），或跨 HTTP 请求传递 —— 会话对象一旦 GC 或连接断开，commitTransaction必然失败 - 连接字符串没带
?replicaSet=xxx—— 单节点直连或未指定 replicaSet 的连接，事务命令（startTransaction）直接返回CommandNotFound，但部分驱动不抛异常，静默降级为普通写
