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” 限制，那可就真是因小失大了。
