必须修改服务端参数transactionLifetimeLimitSeconds，且仅在MongoDB 4.2+副本集或分片集群中生效；单机模式不支持事务，云数据库通常锁定该参数需提工单，动态修改需clusterAdmin权限，仅对新事务生效，设过大易致资源耗尽与排查困难。
不能靠客户端设置，必须改服务端参数 transactionLifetimeLimitSeconds，且只在 MongoDB 4.2+ 副本集或分片集群中生效；单机模式不支持事务，改了也白改。
确认环境是否支持该参数
很多人改完没效果，是因为根本没跑在支持的环境上。先连上去执行两行命令：
-
db.version()—— 必须 ≥ 4.2，4.0 不认这个参数 -
rs.status()或sh.status()—— 返回结果不为空才算副本集或分片集群；如果报错not master或直接提示 “not running with --replSet”，说明是单机模式，事务本身就不可用
云数据库（如 MongoDB Atlas、阿里云 MongoDB）通常锁定该参数，控制台搜不到 transactionLifetimeLimitSeconds 就得提工单，别白折腾 adminCommand。
修改 transactionLifetimeLimitSeconds 的两种方式
它控制事务从 startTransaction() 开始到被强制中止的总秒数（含空闲、锁等待、执行），默认 60 秒。注意：这不是“允许慢操作”，而是“最多容忍挂多久”。
- 动态修改（需
clusterAdmin权限）：db.adminCommand({ setParameter: 1, transactionLifetimeLimitSeconds: 120 })，返回{ "ok": 1 }才算成功；已运行的事务仍按旧值倒计时，只影响新开事务 - 配置文件持久化（推荐）：编辑
/etc/mongod.conf（Linux）或对应路径的配置文件，在setParameter下加一行：transactionLifetimeLimitSeconds: 120，然后重启 mongod
分片集群下，所有 mongos 和 shard 节点的该参数都会参与决策，最终取最小值——别只改 primary 节点。
为什么调大后事务还是被杀？查 maxTransactionLockRequestTimeoutMillis
事务超时不是唯一杀手。即使 transactionLifetimeLimitSeconds 设成 300 秒，也可能卡在锁等待阶段就被干掉，错误通常是 LockTimeout 或 InterruptedDueToReplStateChange。
- 这个参数控制“想拿锁但拿不到时最多等多久”，默认仅 5000 毫秒（5 秒）
- 同样需服务端配置：
db.adminCommand({ setParameter: 1, maxTransactionLockRequestTimeoutMillis: 30000 })，最低不能设低于 1000 - 它和事务总时长无关，专治写冲突场景；若业务常有并发更新同一文档，必须同步调高它
但光调这两个参数没用——如果事务里做了 HTTP 请求、文件读写、或没加超时兜底，服务端再宽容也救不了。
驱动层必须做兜底，否则参数再大也没意义
服务端参数只是最后一道防线，真正可控的是你写的代码。Node.js 和 Python 驱动常见反模式：
- 调了
session.startTransaction()后没await任何操作，或者中间 await 一个没 timeout 的网络请求 - 没给整个事务块设上限，比如用
Promise.race([txPromise, setTimeout(...)])包裹 - Python PyMongo 中漏掉
with timeout(...)：上下文管理器
事务超时后，commitTransaction() 必然失败，报 NoSuchTransaction 或 TransactionTooOld；此时只能调 abortTransaction()，然后重走完整业务逻辑——别幻想“续传”。
真正难的不是调参，是区分清楚：事务卡住到底是真耗时长，还是锁冲突、索引缺失、网络分区或客户端发呆。参数调太大反而掩盖问题，让 oplog 堆积、连接池吃紧、排查变困难。实测典型链路耗时，再乘 1.5 倍设值，比拍脑袋填 300 更可靠。
