根本原因是heartbeatfrequencyms和transactionlifetimelimitseconds未适配高延迟网络，导致心跳失准与事务超时；应将heartbeatfrequencyms设为2000ms、transactionlifetimelimitseconds调至180秒，并用外层context统一控制事务生命周期。
高延迟网络下 MongoDB 事务失败，根本原因不是事务本身不支持，而是默认心跳检测和事务超时参数在跨地域、弱网或云厂商 VPC 跨可用区场景中严重不匹配——heartbeatFrequencyMS 和 transactionLifetimeLimitSeconds 这两个值没调，事务就大概率卡在 commitTransaction 阶段直接超时回滚。
事务提交卡住并报 “Transaction is not in progress” 或 “context deadline exceeded”
这是最典型的表象。实际不是事务没开启，而是客户端发出了 commitTransaction 命令，但主节点还没来得及响应，连接就被驱动层或网络中间件（如 SLB、Nginx）主动断开。背后触发链通常是：
-
serverSelectionTimeoutMS（默认 30s）先超时，导致驱动无法选出可用 server - 或
socketTimeoutMS（默认 0，即无限）虽未触发，但副本集心跳已连续失败多次，驱动将该节点标记为Unknown - 事务上下文丢失，后续任何操作都报
Transaction is not in progress
解决思路不是加重试逻辑，而是让心跳和事务生命周期“跟得上”真实网络延迟。例如跨 AZ 网络 RTT 达到 80ms，那默认 10s 心跳间隔（heartbeatFrequencyMS=10000）就太长——节点可能已失联 20s，驱动却还傻等下一次心跳。
调整 heartbeatFrequencyMS 与 electionTimeoutMillis 的配比关系
心跳频率必须显著小于选举超时，否则副本集会误判节点宕机。但也不能设得太小，否则增加无谓的网络压力。实操建议如下：
- 若网络 RTT 稳定在 50–100ms，设
heartbeatFrequencyMS=2000（2秒），electionTimeoutMillis=10000（10秒），比例保持 1:5 - 若部署在公有云跨 region 场景（RTT > 200ms），
heartbeatFrequencyMS不建议低于 5000，同时必须同步调大electionTimeoutMillis至 ≥30000 - 修改方式：在启动
mongod时通过--heartbeatFrequencyMillis参数，或在副本集配置中用rs.reconfig()更新settings.heartbeatFrequencyMillis
注意：heartbeatFrequencyMS 是客户端驱动读取的配置，不是服务端运行时参数；而 electionTimeoutMillis 是服务端生效的，两者需协同调整，否则会出现“心跳正常但选举频繁失败”的矛盾现象。
transactionLifetimeLimitSeconds 必须覆盖端到端网络抖动周期
MongoDB 服务端强制限制事务最长存活时间，默认是 60 秒。这个值在局域网没问题，但在跨城专线或 4G/5G 回传链路下，一次 find + update + commitTransaction 的耗时很容易突破 60s——尤其当其中某次 socket read 因丢包重传卡住 20s 以上时。
- 生产环境建议设为
180（3分钟），上限不超过360（6分钟）；再长会导致 oplog 压力陡增，影响复制流稳定性 - 该参数只能通过
setParameter命令动态设置：db.adminCommand({ setParameter: 1, transactionLifetimeLimitSeconds: 180 }) - PHP/Go/Node.js 驱动无需额外配置，但必须确保事务内所有操作（含重试）都在这个窗口内完成；否则服务端会在后台自动 abort
真正容易被忽略的是：这个参数不作用于单条命令超时，而是整个事务上下文的“生命计时器”。哪怕你每个 find 都设置了 5s context timeout，只要事务开启后总耗时超限，照样被 kill。
Go 和 Node.js 驱动里 context 超时必须嵌套在事务外层
很多团队给每个 FindOne 或 InsertOne 单独设 context timeout，结果发现没用——因为事务上下文（session.StartTransaction() 返回的 session）有自己的生命周期管理，驱动只在 commit/abort 阶段才检查外层 context。
- 正确做法：用一个带 timeout 的 context 启动事务，后续所有操作复用该 context
- Go 示例：
ctx, cancel := context.WithTimeout(parentCtx, 150*time.Second)，然后session.StartTransaction(&options.TransactionOptions{ReadConcern: ..., WriteConcern: ...}) - Node.js 同理：
const session = client.startSession({ defaultTransactionOptions: { maxCommitTimeMS: 150000 } }) - 切忌在事务内反复 new context，否则事务感知不到超时，服务端 abort 后驱动抛出不可捕获的 panic 或 silent failure
网络延迟不可消除，但事务失败可以预防。关键不是堆资源，而是让心跳、选举、事务时限这三者形成可预期的时序关系——否则再多的重试逻辑，也只是在已失效的上下文中徒劳循环。
