Spring声明式事务通过@Transactional注解保障多表操作原子性，需满足启用配置、正确用法（public方法、代理调用）、单数据源同线程等条件，否则易失效。
Spring 声明式事务通过 @Transactional 注解自动管理事务边界，让多表操作（如插入订单+扣库存+更新用户积分）具备原子性——要么全成功，要么全回滚，从而保障数据一致性。关键不是“加了注解就一定生效”，而是配置、使用和限制都要对。
启用事务管理支持
Spring Boot 项目默认已启用事务管理，但需确认以下两点：
- 启动类或配置类上存在
@EnableTransactionManagement（Spring Boot 2.0+ 通常自动生效，无需显式添加） - 确保有且仅有一个
PlatformTransactionManagerBean（如DataSourceTransactionManager），Spring Boot 会自动装配；若手动定义多个数据源，需明确指定默认事务管理器
@Transactional 正确用法
注解必须作用在 public 方法 上，且调用需走 Spring 代理（即不能在同一个类内 self-invocation 调用）：
- 放在 Service 层方法上（不建议放 Controller 或 Mapper 层）
- 方法必须是 public，private/protected 方法加注解无效
- 调用方必须是 Spring 管理的 Bean（例如通过 @Autowired 注入），直接 new 实例或 this. 调用不会触发事务
- 默认只对
RuntimeException和Error回滚；若需对检查异常（如 SQLException）也回滚，需显式声明：@Transactional(rollbackFor = Exception.class)
多表操作一致性保障要点
只要所有数据库操作由同一数据源的同一个 JdbcTemplate、MyBatis Mapper 或 JPA Repository 完成，且在同一个 @Transactional 方法内执行，Spring 就能保证它们处于同一事务中：
立即学习“Java免费学习笔记（深入）”；
- 例如：转账场景中，
update account set balance = ... where id = ?和insert into transaction_log(...) values(...)都走同一个DataSource，事务自然涵盖两者 - 避免在事务方法内混用不同 ORM 框架（如一半 JdbcTemplate、一半 MyBatis）却未统一事务管理器，否则可能意外脱离事务上下文
- 慎用
saveAndFlush()或executeUpdate()后立即查库验证——Hibernate 的一级缓存可能导致“查到未提交数据”，不代表已持久化
常见失效场景与规避方式
事务看似加了，但没起作用？多半掉进这些坑：
-
异步调用绕过事务：方法内用了
@Async或新建线程执行 DB 操作，新线程无事务上下文 → 改用TransactionSynchronizationManager手动传播，或重构为同步逻辑 -
事务传播行为误配：比如调用另一个
@Transactional(propagation = REQUIRES_NEW)方法，会启新事务，原事务回滚不影响它 → 多数业务应保持默认REQUIRED - 非受检异常未被捕获：try-catch 吞掉 RuntimeException 却没重新抛出 → 导致事务无法感知异常，最终提交脏数据
- 数据库引擎不支持事务：MySQL 表用 MyISAM 引擎 → 必须改用 InnoDB
不复杂但容易忽略：事务一致性靠的是“单数据源 + 同一线程 + 正确代理 + 未被中断的异常传播”。把这几环对齐，多表操作就能稳稳地要么全成，要么全废。
