MongoDB事务超时由服务端参数transactionLifetimeLimitSeconds控制，默认60秒，客户端maxTimeMS无效；需用adminCommand动态修改，仅对新事务生效，且须权衡资源消耗与业务实际耗时合理设置。
事务超时不是客户端能改的，得动服务端参数 transactionLifetimeLimitSeconds
MongoDB 事务在服务端有硬性生命周期限制，默认就是 60 秒，客户端传 maxTimeMS 只影响单个操作（比如一次 updateOne），对整个事务存活时间完全无效。你看到事务“卡住”或静默回滚，大概率是这个参数在起作用。
修改它必须用 adminCommand，且需管理员权限：
db.adminCommand({ setParameter: 1, transactionLifetimeLimitSeconds: 120 })
执行后会返回 { "ok": 1 } 表示成功。注意：该设置是动态生效的，无需重启 mongod，但只对后续新开启的事务生效——已运行中的事务仍按旧值计时。
别直接设成 300 秒甚至更长，小心连接池和内存被拖垮
延长事务有效期不是越长越好。事务长期挂起会持续占用 session、锁、内存和连接资源，尤其在高并发下容易引发连锁反应：
- 分片集群中，一个慢分片会让整个事务卡死，其他分片空等
- 活跃事务数飙升会挤占连接池，新请求排队或直接失败
- 事务日志（oplog）堆积变多，可能影响副本集同步延迟
建议实测业务典型事务耗时（从 startTransaction 到 commitTransaction），再乘以 1.5 倍作为新值。例如实测平均 42 秒，设为 60–70 秒比盲目拉到 300 秒更稳妥。
云数据库平台可能不开放该参数，优先查控制台或工单
阿里云 MongoDB、MongoDB Atlas 等托管服务通常默认锁定 transactionLifetimeLimitSeconds，普通账号无法执行 adminCommand。这时候：
- 先去控制台「参数管理」或「高级配置」页搜索该参数名
- 部分平台允许白名单用户申请调整，需提交工单说明业务场景和压测依据
- 若完全不可调，只能重构逻辑：把大事务拆成多个 ≤60 秒的小事务，用业务状态字段（如
status: "step1_done"）做衔接和幂等控制
事务超时后不能重试 commit，必须 abort 并重新走流程
一旦事务因超时被服务端自动中止，再调 session.commitTransaction() 必然报 NoSuchTransaction 或 TransactionTooOld。此时：
-
session.abortTransaction()是唯一安全收尾方式（即使已超时，调它也不会报错） - 客户端不能假设“重试 commit 就能续上”，上下文早已清理干净
- 真正要重试的是整个业务逻辑：重新获取数据、校验前置条件、新建 session 再 startTransaction
最容易被忽略的是：很多团队只盯着 maxTimeMS 调优，却没意识到 transactionLifetimeLimitSeconds 才是决定事务能否活过 60 秒的生死线——而且它不在驱动代码里，而在服务器配置里。
