合理重试次数为2～3次，配合指数退避（如100ms、300ms），第3次失败后抛出原错误；每次重试必须开启新事务，不可复用已失败的事务。
遇到 TransientTransactionError 时重试几次才合理
应该重试，但不是无限制重试，更不是只试一次就放弃——典型做法是重试 2～3 次，配合指数退避。
-
TransientTransactionError表示事务因临时性原因失败（如主节点切换、网络抖动、锁冲突），不是数据或逻辑错误，重试大概率成功 - 重试 1 次太激进：刚发生的主从切换可能还没完成，立刻重试仍会失败；重试 5 次以上又浪费资源，还可能掩盖真实问题（比如配置了过短的
transactionLifetimeLimitSeconds） - 推荐策略：第 1 次失败后等待 100ms，第 2 次失败后等待 300ms，第 3 次失败后直接抛出原始错误（不继续）
- 注意：每次重试必须开启新事务（不能复用旧的
session中已失败的事务），否则会报NoSuchTransaction
哪些 TransientTransactionError 类型值得重试
不是所有带 “Transient” 字样的错误都该重试，MongoDB 官方只明确将部分错误归为“可安全重试”的瞬态错误。
- 明确可重试：
Interrupted、NetworkTimeout、NotWritablePrimary、PrimarySteppedDown、ExceededTimeLimit（仅当发生在 commit 阶段） - 不可重试：
WriteConflict（虽然也是瞬态，但需业务判断是否要合并逻辑）、InvalidNamespace、Unauthorized—— 这些是配置或权限问题，重试没用 - 检查方式：不要靠字符串匹配
"Transient"，而应解析响应里的errorLabels数组，确认是否包含"TransientTransactionError"
重试时 session 和 transaction 的生命周期怎么管
Session 对象可以复用，但事务状态不能跨次重试延续——这是最容易出错的地方。
- 每次重试前，必须调用
session.startTransaction()显式开启新事务；不能在旧事务失败后直接调commitTransaction() -
session本身可复用（只要没过期），但它的transaction属性是只读且不可重置的，失败后该 session 的当前事务即终结 - 别漏掉清理：如果重试达到上限，记得调
session.endSession()（尤其在长连接池场景下，避免 session 泄漏） - 常见坑：
session.transaction.state === "TRANSACTION_COMMITTED"或"TRANSACTION_ABORTED"后再调commitTransaction()会直接报错NoSuchTransaction
Node.js 驱动里怎么写一个靠谱的重试封装
用官方驱动（v4.0+）时，别自己手动循环 start/commit，而是利用 withTransaction 的内置重试机制，它已按规范处理了标签识别和退避。
- 直接用：
await session.withTransaction(async () => { /* 你的操作 */ }, { readPreference: "primary", maxCommitTimeMS: 30000 }) - 它默认重试 3 次，且自动识别
errorLabels中的"TransientTransactionError"，无需手动判断错误类型 - 如果需要自定义重试次数或退避逻辑，才需手动实现；此时务必确保每次循环中：新建事务 + 执行业务逻辑 + 显式 commit/abort
- 示例关键片段：
let attempt = 0;<br>while (attempt < 3) {<br> try {<br> await session.startTransaction();<br> await collection.updateOne(...);<br> await session.commitTransaction();<br> break;<br> } catch (err) {<br> if (err.errorLabels?.includes("TransientTransactionError") && attempt < 2) {<br> await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 100));<br> attempt++;<br> continue;<br> }<br> throw err;<br> }<br>}
真正容易被忽略的是：事务超时时间（transactionLifetimeLimitSeconds）和重试间隔的叠加效应。比如设了 60 秒超时，又重试 3 次、每次等 1 秒，那第 3 次开始时只剩不到 57 秒——如果业务逻辑本身慢，很可能还没提交就触发超时，变成另一个 ExceededTimeLimit。得根据实际操作耗时反向压测这个组合值。
