MongoDB完全不支持嵌套事务，因每个会话仅维护一个事务状态位，重复调用startTransaction会抛出TransactionAlreadyInProgress错误；正确做法是将跨集合操作统一纳入单层事务，并确保副本集、事务管理器及代理配置正确。
MongoDB 不支持嵌套事务
直接回答：MongoDB 完全不支持嵌套事务（即在一个已开启的事务内再次调用 startTransaction）。这不是配置问题，也不是版本限制，而是 MongoDB 事务模型的底层设计决定的——每个会话（Session）最多只能有一个活跃事务。
为什么不能嵌套？关键在会话生命周期
MongoDB 的事务必须绑定到一个显式创建的 Session 实例上，而该会话对象内部只维护一个事务状态位。一旦调用 startTransaction，状态变为 “in progress”；此时再调用一次，驱动会直接抛出错误：TransactionAlreadyInProgress（不同语言 SDK 错误名略有差异，但语义一致）。
常见错误现象：
- Java Spring 中
@Transactional方法内调用另一个@Transactional方法（未设propagation = Propagation.REQUIRES_NEW）→ 实际仍是同一个事务上下文，但 Spring 无法真正“嵌套”，只会忽略内层注解或报错 - Node.js 手动管理 session 时，在
session.startTransaction()后又写了一次 → 抛出TransactionAlreadyInProgress - PHP 使用
$session->startTransaction()两次 →MongoDB\Driver\Exception\RuntimeException
替代方案：用单层事务 + 显式逻辑编排
需要“类似嵌套”的业务（比如订单创建含库存扣减+日志记录+优惠券核销），正确做法是把所有操作收拢进**同一个事务块**，由应用层统一控制边界，而不是靠嵌套来隔离。
实操建议：
- 把跨集合操作（如
orders、inventory、vouchers）全部放在一个session内执行，用commitTransaction()或abortTransaction()一并提交或回滚 - 避免在事务回调函数中再开新 session —— 这看似“解耦”，实则破坏原子性，且容易因连接/超时导致部分成功、部分失败
- 如果某步逻辑确实要独立成败（比如发通知失败不应影响订单入库），那就把它移出事务体，改用补偿机制（如消息队列 + 幂等处理）
注意：分片集群下还有额外约束——事务内所有集合必须落在同一分片上，否则直接报 MultiNamespaceTransactionNotSupportedOnShardedCluster。
Spring Boot 开启事务前最容易漏的三件事
很多开发者以为加了 @Transactional 就万事大吉，结果事务根本不生效，根本原因常卡在这三点：
实操检查项：
-
application.yml中必须启用副本集连接：URI 要包含多个节点（如mongodb://node1:27017,node2:27017/...），单机模式（localhost:27017）即使版本 ≥4.0 也不支持事务 - 必须显式声明
MongoTransactionManagerBean，并确保它被 Spring 容器识别（常被 @Configuration 类漏掉或条件化失效） - 方法不能是
private、final或被本类内其他方法直接调用（Spring AOP 代理失效），必须走接口或 CGLIB 代理路径
最隐蔽的一点：MongoDB 驱动默认不开启事务支持，transactionEnabled: true 是 Spring Data MongoDB 的自定义开关，不是 MongoDB 服务端配置——它只控制是否注册 MongoTransactionManager，不控制服务端能力。
