@Transactional默认仅对RuntimeException和Error回滚，非运行时异常需显式配置rollbackFor=Exception.class才回滚，且必须通过Spring代理调用、方法为public、事务管理器正常加载才能生效。
@Transactional 默认就回滚，不是“要加才回滚”，而是“加了才可能不回滚”——这是绝大多数人踩坑的起点。
为什么 @Transactional + @Rollback 在 @SpringBootTest 里看起来没生效
根本原因不是注解没起作用，而是事务管理器压根没加载进来。常见触发场景：
- 测试类用了
@ExtendWith(MockitoExtension.class)却没配@SpringBootTest，此时 Spring 上下文未启动，@Transactional形同虚设 - 手动 new 出 Service 实例（比如
new UserServiceImpl()），绕过了 Spring 的代理机制，事务切面完全不介入 - 测试方法上写了
@Transactional(propagation = Propagation.REQUIRES_NEW)，新事务独立提交/回滚，外层事务控制不了它 - 调用了非 Spring 管理的对象（如裸 JDBC
Connection、JdbcTemplate外部封装），这些操作不在事务同步器管理范围内
@DataJpaTest 自带回滚，但只管 JPA 层
它本质是轻量级的 @SpringBootTest 切片，自动启用事务、配好 H2、加载 JpaRepository Bean。但它不加载 @Service 或 @Controller，所以：
- 适合测
userRepository.save()、userRepository.findByEmail()这类纯 Repository 方法 - 不适合测 service 方法里嵌套的事务传播行为（比如
@Transactional嵌套调用） - 如果 service 中混用了
RedisTemplate或RestTemplate，这些操作不会被回滚，得靠@BeforeEach手动清理 - 想换 MySQL 测试？必须显式加
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)并确保application-test.yml里有真实 DB 配置
@SpringBootTest + @AutoConfigureTestDatabase 的组合陷阱
这个组合常被当成“全链路回滚万能解”，但实际容易掉进两个坑：
- 没加
@Transactional：默认不开启事务边界，DB 操作直接提交；必须在类或方法上显式标注@Transactional - 误用
@Rollback(false)：本意是验证提交后状态，却忘了只该用在极少数 case（比如测试幂等写入），多数时候加了反而破坏隔离性 - Web 层测试中用了
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)，但没确认 Controller 层是否真的走到了 JPA 层——如果中间被 Mock 掉或抛了异常提前退出，事务甚至没机会开启 - 多线程操作（如
@Async方法）会脱离当前事务上下文，回滚失效且无报错，只能靠日志或断点确认执行路径
真正稳定的回滚闭环，得靠分层选型+显式约束
没有银弹，只有匹配场景的组合：
- 只测 Repository：用
@DataJpaTest，删掉所有@Transactional相关手动配置，它已内置 - 测完整 MVC → Service → DB 链路：用
@SpringBootTest+ 类级别@Transactional，禁用@Rollback（除非特殊需要） - 涉及外部系统（Redis/Kafka）：接受“部分不可回滚”，用
@BeforeEach清 Redis key、用 Testcontainers 启停临时 Kafka 实例，别强求单事务兜底 - CI 环境跑不通？检查
spring-boot-starter-test是否在testscope，Maven profile 是否激活了test配置，H2 驱动是否被其他依赖意外排除
最易被忽略的一点：事务回滚只对数据库有效，对静态变量、本地缓存、文件写入、HTTP 调用结果毫无影响。一旦测试里出现这类副作用，再严格的 @Transactional 也救不回来。
