MongoDB 事务如何通过 Mongoose 使用_Node.js 环境下 session 机制的实战应用

Mongoose 6.0+ 事务实战：绕开那些“静默失效”的坑

Mongoose 6.0+ 默认支持 MongoDB 原生事务，但需在连接就绪（readyState === 1）后调用 startSession() 获取有效 session，且每个事务必须使用独立 session 并显式传入 { session } 选项；session.withTransaction() 自动处理重试与回滚，手动方式需严格调用 start/commit/abortTransaction() 并及时 endSession() 防止资源泄漏。

先说一个核心结论：从 Mongoose 6.0 开始，虽然原生事务支持是默认开启的，但这绝不意味着你可以“开箱即用”。最关键的一步，是你必须显式创建并传入 session 对象。否则，你的 session.startTransaction() 要么直接报错，要么更糟——静默失效，让你误以为事务在保护你的数据，实则不然。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

为什么你的 session.startTransaction() 会报 “TopologyDescription not connected”？

这通常不是语法问题，而是 session 对象本身就没绑定到一个可用的数据库连接上。Mongoose 的 startSession() 必须在连接完全就绪后才能调用，而且一个 session 绝不能“重复利用”。

• 连接时机是关键：mongoose.connect() 是异步操作。你得确保在 mongoose.connection.readyState === 1 之后，再调用 mongoose.startSession()。在连接回调或 Promise 解析前创建 session，是这类错误的常见根源。
• 一事务一 session：每个独立的事务都必须使用自己专属的 session。别想着把一个 session 拿来多次调用 startTransaction()，这行不通。
• 警惕“绕路”：如果你直接使用 mongoose.connection.db.startSession()（这是 MongoDB 原生驱动的方式），就等于绕过了 Mongoose 自身的连接状态管理，很容易触发 topology 相关的连接错误。

session.withTransaction() 和手动 commitTransaction()，到底怎么选？

这是两种风格迥异的路径。withTransaction() 是封装好的“自动驾驶”模式，自带错误回滚和重试逻辑，适合绝大多数标准业务场景。而手动控制，则把方向盘完全交给你，适用于那些需要对提交或回滚时机进行精细干预，或者需要捕获中间状态的复杂流程。

• 推荐首选：session.withTransaction(async () => { ... })：这个方法会自动处理“瞬时事务错误”的重试（默认最多5次），一旦失败，也会自动执行 abortTransaction()。省心，且健壮。
• 手动流程，步骤必须严格：如果选择手动，顺序不能乱：session.startTransaction() → 执行你的数据操作 → 最后 await session.commitTransaction() 或 await session.abortTransaction()。
• 别忘了清理：手动模式下，如果一个 session 既没有提交也没有中止，它会一直占用服务器资源。默认60秒后，服务端会强制终止它，但客户端的 session 引用并不会自动释放，这可能成为内存泄漏的隐患。

跨 Model 的写操作，必须共用同一个 session

这一点至关重要，却常被忽略。Mongoose 的 sa ve()、deleteOne()、updateMany() 等方法，只有当你显式传入 { session } 选项时，它才会被纳入当前事务的上下文中。否则，它们就是独立操作，不受事务保护。

• 典型错误：await User.create({...}) —— 即使你有一个活跃的 session，这行代码也不会进入事务。
• 正确姿势：await User.create({...}, { session }) 或 await user.sa ve({ session })。记住，那个 { session } 对象是事务的“门票”。
• 注意批量操作：Model.insertMany() 支持 { session } 选项。但到了 bulkWrite() 这里，你需要为其中的每一个操作单独加上 session 字段，例如：{ updateOne: { filter, update, session } }。
• 查询操作呢？：查询方法（如 find, findOne）加上 { session } 后，可以读取到本事务中尚未提交的数据，实现“读己之所写”。但这并非强制要求，取决于你的业务逻辑是否需要这种隔离性。

事务里调用 aggregate() 或 countDocuments()，兼容性如何？

从 MongoDB 4.2 版本起，事务内已经支持聚合管道操作（包括 $lookup、$facet 等阶段）。但在 Mongoose 中使用时，语法有讲究：Model.aggregate().session(session) 必须采用链式调用，并且要避免在管道中混入非事务集合的操作。

• 正确写法：await User.aggregate([...]).session(session).exec() 这是有效的。
• 计数也支持：await User.countDocuments(filter, { session }) 这在 Mongoose 6.7+ 版本中是受支持的。
• 重要限制：事务内返回的是数据快照。更要警惕的是，如果聚合管道中使用了 $out 或 $merge 这类写入到其他集合的操作符，MongoDB 会直接报错——事务内不允许写入到其他集合。
• 分片集群警告：在分片集群环境下，事务内所有操作涉及的数据，必须落在同一分片键的范围内。跨分片的写入在事务中是禁止的。

话说回来，整个流程中最容易被忽视的一环，其实是 session 的生命周期管理。它不像某些框架的请求上下文那样会自动清理。你必须确保在每次事务结束后，无论是成功还是失败，都主动调用一下 session.endSession()。否则，连接池里残留的 session 对象会不断堆积。尤其是在高并发、短事务的业务场景下，这很可能触发服务端的 “Too many sessions” 限制，那可就真是因小失大了。