startsession() 后事务不生效的根本原因是未调用 session.starttransaction() 且操作未显式传入 { session } 选项；withtransaction() 需在回调中 throw 错误才能回滚，不捕获业务异常。
为什么 startSession() 调用后事务不生效
常见现象是调用了 startSession()，也传了 session 给 save() 或 deleteOne()，但操作仍独立提交、回滚无效。根本原因：MongoDB 事务要求所有操作必须在同一个 session 上显式绑定，且该 session 必须已启动（session.startTransaction()）并**未被提前结束**。
实操要点：
-
session创建后必须手动调用session.startTransaction()，否则后续操作不进入事务上下文 - 所有参与事务的 Model 操作（
save()、updateOne()、deleteMany()等）都必须显式传入{ session }选项，不能只靠闭包或全局变量“默认生效” - Mongoose 的
exec()、then()不会自动透传session；Promise 链中每一步都要重新带{ session } - 事务内禁止跨数据库操作（如同时写
users和logs库），除非用同一client并指定db实例（Mongoose v6.8+ 支持多库事务，但需同 replica set）
withTransaction() 的正确用法与失败重试逻辑
withTransaction() 是封装了启动、提交、回滚、自动重试（针对可重试错误如 TransientTransactionError）的工具方法，但它**不会自动捕获业务逻辑异常**——你仍需在回调里 throw 错误来触发回滚。
典型误用：在 withTransaction() 回调里用 try/catch 吞掉错误，导致事务静默提交。
实操建议：
- 把全部数据库操作放在
withTransaction()的回调函数内，不要在外部做条件判断或 I/O（如 HTTP 请求、文件读写） - 回调函数必须返回一个 Promise；若中间某步失败（如校验不通过），直接
throw new Error('xxx')，由withTransaction()捕获并回滚 - 需要自定义重试行为时，传入
retryOptions，例如：{ maxRetries: 2, delayMs: 100 }；默认只对TransientTransactionError重试，不重试ValidationError或网络超时 - 注意：Mongoose v7 默认启用
retryWrites: true，但withTransaction()的重试是上层逻辑控制，和驱动层retryWrites无关
事务中使用 findOneAndUpdate() 的坑
findOneAndUpdate() 在事务中容易出错，典型报错：Cannot use a session that has ended 或更新结果为 null 即使文档存在。
根本问题：该方法底层可能触发两次查询（先 find 再 update），若未显式传 { session }，第二次操作会脱离事务上下文。
必须做到：
- 所有
findOneAndUpdate()调用都带上{ session, returnDocument: 'after' }（后者确保返回更新后状态，避免脏读） - 不能依赖
new: true（已被废弃），必须用returnDocument - 如果更新涉及数组字段（如
$push），确保索引操作符（如$[elem]）匹配规则在事务内一致；事务不保证跨语句的查询缓存一致性 - 避免在事务中对同一文档高频
findOneAndUpdate()—— 可能因写冲突（WriteConflict）反复重试失败
生产环境事务性能与兼容性注意事项
MongoDB 事务不是银弹。开启事务会显著增加锁持有时间与内存开销，尤其在高并发短事务场景下易引发排队。
关键限制与取舍：
- 事务最大持续时间默认 60 秒（
transactionLifetimeLimitSeconds），超时自动中止；长流程（如用户导入）必须拆分为多个短事务 - 单个事务内操作文档总大小不能超过 16MB（含 BSON 开销），批量插入需分片控制
- 副本集必须是 3 节点以上且启用 majority 读写关注（
w: "majority"），否则事务无法初始化 - Mongoose 连接字符串需显式开启 replica set 支持：
?replicaSet=rs0&readPreference=primary；仅连接单机 mongod 时事务会静默降级为普通操作 - 日志里出现
Transaction numbers are only allowed on a replica set就说明配置未达标，不是代码问题
真正难处理的从来不是怎么写 withTransaction()，而是判断哪段业务逻辑**必须**用事务 —— 比如账户余额扣减 + 订单创建，漏掉任何一个环节的 session 传递，整个一致性就崩了。
