Propagation.REQUIRED嵌套调用会触发rollback-only异常，因为内层复用外层事务对象，抛异常后标记rollback-only，外层catch后仍尝试提交导致UnexpectedRollbackException；需改用REQUIRES_NEW或NESTED。
默认的 Propagation.REQUIRED 在嵌套调用中无法隔离异常影响，外层事务捕获内层异常后会抛出 UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only —— 这不是 bug，而是传播机制的必然结果。
为什么 Propagation.REQUIRED 嵌套调用会触发 rollback-only 异常
Spring 事务是基于 AOP 代理 + 线程绑定 TransactionStatus 实现的。当内层方法（如 serviceB.b()）被 @Transactional(propagation = Propagation.REQUIRED) 修饰，且当前已有外层事务时，它直接复用同一事务对象。
一旦内层方法抛出未被捕获的异常（比如 RuntimeException），Spring 的 completeTransactionAfterThrowing 会调用 rollback()，并将该事务状态标记为 rollback-only。此时外层方法若用 try-catch 吞掉异常并继续执行，等外层方法正常结束时，Spring 发现事务已是 rollback-only 却要 commit()，就强制抛出 UnexpectedRollbackException。
- 关键点：事务对象是共享的，
rollback-only是写在同一个TransactionStatus实例上的布尔标记 - 常见误判：以为“catch 了异常就等于事务没受影响”，实际事务状态早已不可逆地被污染
- 典型错误代码：
serviceA.a()调用serviceB.b()，b()抛RuntimeException，a()中catch后继续执行 insert 操作
想让内层失败、外层仍能提交，必须换传播行为
只有 Propagation.REQUIRES_NEW 或 Propagation.NESTED 能打破事务共享，但二者语义和兼容性完全不同：
-
Propagation.REQUIRES_NEW：完全新建物理事务，挂起外层事务；内层回滚不影响外层，外层回滚也不影响内层已提交的数据；要求数据库支持事务挂起（如 MySQL 5.7+、PostgreSQL 都支持） -
Propagation.NESTED：不新建事务，而是在当前事务内设savepoint；内层失败仅回滚到 savepoint，外层仍可提交；依赖数据库 savepoint 支持（MySQL InnoDB 支持，MyISAM 不支持） -
Propagation.SUPPORTS/Propagation.NOT_SUPPORTED等不开启事务，无法控制内层回滚，排除
示例（推荐 REQUIRES_NEW 场景）：
@Service
public class ServiceA {
@Resource private ServiceB serviceB;
@Transactional
public void a() {
// 外层事务：插入用户
userMapper.insert(...);
try {
serviceB.b(); // 内层独立事务
} catch (Exception e) {
// 忽略，不影响外层
}
// 外层继续执行并提交
logMapper.info("user created");
}
}
@Service
public class ServiceB {
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void b() {
// 即使这里抛 RuntimeException，只回滚本事务
orderMapper.create(...);
throw new RuntimeException();
}
}
别忽略 rollbackFor 和数据库引擎限制
传播行为只是第一步，两个硬性条件不满足，任何传播设置都无效：
-
@Transactional(rollbackFor = Exception.class)必须显式声明：Spring 默认只对RuntimeException和Error回滚，Exception及其子类（如IOException）不会触发回滚，即使传播行为正确 -
Propagation.NESTED要求 JDBC 驱动开启savepoint支持（Spring 默认开启，但需确认DataSource未禁用），且底层数据库引擎必须支持（MySQL 的 MyISAM 表不支持 savepoint，InnoDB 才行） -
Propagation.REQUIRES_NEW在某些连接池（如 HikariCP）中可能因连接复用导致事务隔离失效，建议配合isolation = Isolation.DEFAULT使用，避免手动指定隔离级别干扰挂起逻辑
最易被忽略的调试线索：日志里看事务是否真的“新”了
当怀疑传播行为没生效时，不要只查代码注解，直接看 Spring 事务日志（开启 org.springframework.transaction DEBUG 级别）：
- 出现
Creating new transaction→REQUIRES_NEW生效 - 出现
Participating in existing transaction→ 还是REQUIRED，检查是否加在 private 方法、this 调用或非代理对象上 - 出现
Setting savepoint for nested transaction→NESTED生效，否则可能是数据库不支持或 JDBC 配置问题
真实项目里，REQUIRES_NEW 更可控；NESTED 看似轻量，但 savepoint 的回滚粒度、与数据库锁的交互、以及部分 ORM 框架（如 MyBatis）对 savepoint 的兼容性，都比表面复杂得多。
