exceededtimelimit 是客户端网络超时而非事务超时，因 committransaction 的两阶段协议依赖跨分片网络往返，maxtimems 不生效；应调大 sockettimeoutms 等网络参数，并避免事务内阻塞操作。
ExceededTimeLimit 不是事务本身超时，而是客户端在等待 commitTransaction 响应时网络层面超时了——服务端可能早已提交成功，但回包卡在网络或 mongos 层，客户端等不到就直接报错。
为什么 maxTimeMS 对 commit 没用
maxTimeMS 只约束单个操作（如 updateOne、find）的执行耗时，不覆盖 commitTransaction 的网络往返时间。事务 commit 是一个两阶段协议：协调分片先发 prepare 给所有参与分片，等全部响应后再发 commit；任意一跳网络延迟、mongos 负载高、或某个分片响应慢，都会让客户端干等，最终触发驱动层的 socket 或 server selection 超时。
-
maxTimeMS必须在startTransaction({ maxTimeMS: 12000 })里传入，写在commitTransaction()调用里无效 - 分片集群中，
maxTimeMS只作用于 coordinator shard 上的主操作，对跨分片广播和等待完全不生效 - 常见误判：看到日志里
ExceededTimeLimit就去调transactionLifetimeLimitSeconds，其实两者无关
该调哪些网络超时参数
真正要改的是驱动连接池和网络层的超时配置，不是事务生命周期参数。不同语言驱动暴露的选项名略有差异，但核心就三个：
-
socketTimeoutMS：单次读/写操作等待响应的上限（默认 30s），commitTransaction卡住时最先触发它 -
serverSelectionTimeoutMS：找不到可用 mongos/shard 的等待时间（默认 30s），网络分区或 mongos 挂掉时会先报这个 -
connectTimeoutMS：建立新 TCP 连接的上限（默认 10s），部署在弱网环境（如跨云厂商）时容易触发
Node.js 示例：MongoClient("mongodb://...", { socketTimeoutMS: 60000, serverSelectionTimeoutMS: 45000 })
为什么调大后还是报错？检查锁等待和逻辑阻塞
即使网络通畅，commitTransaction 也可能被卡在服务端锁等待上——比如另一个长事务正锁着某条文档，当前事务在 prepare 阶段等锁，而默认 maxTransactionLockRequestTimeoutMillis 是 5000ms（5秒），超时就抛 WriteConflict，但错误信息常被客户端包装成模糊的 ExceededTimeLimit。
- 动态调高它：
db.adminCommand({ setParameter: 1, maxTransactionLockRequestTimeoutMillis: 30000 }) - 更治本：把事务内 HTTP 请求、循环计算、文件 IO 全部移出去，只留必要 DB 操作
- 确认是否真卡在 commit：连到 mongos 执行
db.currentOp({ "secs_running": { "$gt": 10 }, "secs_running": { "$lt": 300 } })，看是否有commitTransaction状态为inDoubt或waitingForLock
最易被忽略的一点：ExceededTimeLimit 报错后，不能重试 commitTransaction——上下文已被清理，再调必报 NoSuchTransaction。必须先 abortTransaction()，再重建 session 重走完整业务流程。
