MongoDB事务不能在mongosh中长期挂起，根本原因是服务端对空闲事务强制终止（默认60秒），与客户端无关；mongosh作为交互式REPL无法保证事务操作原子性，必须用await链式调用或脚本一次性执行。
MongoDB 事务不能在 mongosh 中长期挂起，根本原因不是 shell 本身限制，而是服务端对「空闲事务」的强制终止策略 —— 它压根不区分你是用 mongosh、驱动程序还是其他客户端，只要事务 session 空闲超过阈值，就直接 kill。
为什么 mongosh 里 startTransaction() 后不操作就卡住，过一会儿报错？
这是最典型的误用场景：mongosh 是交互式 REPL，你输入 session.startTransaction()，回车执行了，但没紧接着发写操作或 commitTransaction()，shell 就停在那里等你下一条命令。此时事务已开启，但服务端开始倒计时。
关键点在于：
- MongoDB 服务端默认只给事务 60 秒 总生命周期（含等待+执行），由
transactionLifetimeLimitSeconds控制 -
mongosh不会自动帮你提交或回滚；它只是个命令行客户端，不带业务逻辑兜底 - 你敲完
session.startTransaction()后发呆 65 秒 → 服务端超时 abort，再执行insertOne(..., { session })就会报Transaction is not in progress或Transaction was aborted - 这个超时是服务端行为，
mongosh连接本身可能还活着，但事务上下文已销毁
mongosh 事务必须「一气呵成」，不能分多步手动敲
你在文档里看到的示例代码，比如先 startTransaction()，再 insertOne()，最后 commitTransaction()，这些是放在一个 async 函数块里同步执行的。而 mongosh 的交互模式天然割裂了这种原子性。
可行做法只有两种：
- 把整个事务逻辑写成一段可执行的 JS 脚本，用
mongosh script.js一次性跑完 - 在
mongosh里用await链式调用，例如：const session = db.getMongo().startSession();<br>await session.withTransaction(async () => {<br> await db.orders.insertOne({ status: "pending" }, { session });<br> await db.inventory.updateOne({ sku: "abc" }, { $inc: { qty: -1 } }, { session });<br>});<br>await session.endSession(); - 千万别拆成三行分别敲：第一行启动，第二行发呆，第三行插入 —— 这等于主动触发超时
即使改大 transactionLifetimeLimitSeconds，mongosh 仍不适合调试长事务
你可以通过 rs.conf() + rs.reconfig() 动态调大该参数，或写入配置文件重启。但要注意：
- 该参数最低允许值是
1秒，但生产环境不建议设太高（比如 >300），否则可能堆积大量未决事务，拖慢 oplog 应用和复制延迟 - 调大后，事务仍可能因锁等待超时被干掉 —— 比如你手敲到一半，另一个应用正在独占更新同一文档，
mongosh会卡在updateOne上，最终触发maxTransactionLockRequestTimeoutMillis（默认 5 秒） -
mongosh没有事务状态监控命令，你无法实时查「当前有哪些事务活着」「它们卡在哪一步」，只能靠日志或db.currentOp({ "secs_running": { "$gt": 5 } })猜 - 真正需要调试事务逻辑时，应该用 Node.js/Python 等语言写最小复现脚本，加
console.log和try/catch，而不是依赖mongosh的交互节奏
事务不是交互式玩具，它是服务端严格管控的状态机。mongosh 只负责传指令，不负责保状态 —— 你敲得越慢，服务端关得越快。
