MongoDB不支持嵌套事务，Propagation.NESTED在MongoTransactionManager中被忽略并退化为REQUIRED；因其事务模型无savepoint机制，无法实现部分回滚，应优先利用单文档原子性或Saga等补偿方案。
Spring Data MongoDB 本身不支持嵌套事务——这不是配置问题，而是能力边界问题。 MongoDB 的多文档事务（包括 Spring 的 @Transactional）只支持单层事务，Propagation.NESTED 在 MongoTransactionManager 中完全被忽略，调用时会静默退化为 PROPAGATION_REQUIRED。你写的嵌套事务逻辑，实际跑的只是普通事务。
为什么 @Transactional(propagation = Propagation.NESTED) 在 MongoDB 里无效
MongoDB 官方从 4.0 开始支持多文档事务，但仅提供“扁平事务”模型：一个会话（session）对应一个事务，不支持 savepoint、不支持部分回滚、不支持嵌套作用域。Spring 的 PROPAGATION_NESTED 依赖 JDBC 的 Savepoint 机制，而 MongoTransactionManager 没有实现该语义，源码中直接抛出 IllegalStateException 或 fallback 到 required 行为。
-
MongoTransactionManager.doBegin()不创建 savepoint，也不维护嵌套状态 - 调用
TransactionStatus.createSavepoint()会触发 UnsupportedOperationException - 即使你在方法上写
@Transactional(propagation = Propagation.NESTED)，运行时日志里也看不到任何嵌套痕迹
嵌套逻辑误用：把业务分段当成事务分段
常见错误是把“先扣库存、再写日志、再发消息”这类顺序操作，强行拆成多个 @Transactional 方法并期望能局部回滚。但在 MongoDB 里：
- 每个
@Transactional方法都开启/提交独立事务 → 数据一致性无法保障（例如库存扣了，日志写失败，事务已提交） - 若试图用
this.methodB()自调用模拟嵌套 → 代理失效，第二个事务注解根本没触发 - 跨方法加事务 + 同类调用 → 实际变成多个无关联的短事务，比不用还危险
真正可行的替代方案
放弃“嵌套事务”思路，转向 MongoDB 原生优势和补偿设计：
-
单文档原子性优先：把库存数量、变更历史、状态时间戳全塞进同一个
InventoryDocument，用findAndModify更新，天然避免跨文档事务 -
两阶段写入 + 状态机：写操作分
PENDING→CONFIRMED两步，异步任务扫描超时PENDING记录做补偿或清理 - Change Stream 监听 + Saga：用 Change Stream 捕获库存变更事件，触发下游日志写入；失败时通过反向操作（如“恢复库存”）补偿
- 如果真需强一致性跨集合操作，
@Transactional只能用一层，且必须确保所有操作在同一个MongoTemplate和ClientSession下执行
最容易被忽略的一点：MongoDB 事务不是性能友好型功能。开启事务后，所有读写都走全局逻辑时钟协调，吞吐下降明显。别为了“看着像 MySQL”就给每个 Service 方法套 @Transactional——先重构文档结构，再考虑是否真需要事务。
