Java事务管理需按场景选型：声明式（@Transactional）简洁解耦，适用于大多数情况；编程式（TransactionTemplate/PlatformTransactionManager）灵活可控，适合动态事务边界。必须配对匹配数据源的事务管理器（如JDBC用DataSourceTransactionManager），注意传播行为、隔离级别、代理调用及异常处理等关键细节。
Java 事务系统不是“配”出来的，而是根据应用场景、数据源类型和框架能力合理选型并正确编码实现的。核心在于理解事务边界、传播行为、隔离级别与底层资源（如 JDBC、JTA）的联动关系，而不是简单堆配置。
明确事务管理方式：编程式 or 声明式？
Spring 中主流用声明式事务（@Transactional），开发简洁、解耦好；编程式（TransactionTemplate 或 PlatformTransactionManager）适合动态控制事务边界（比如条件开启/回滚）。
- 声明式需开启注解驱动：
@EnableTransactionManagement（Java Config）或 - 确保目标方法被 Spring 代理调用（避免 self-invocation 失效）
- 非 public 方法上 @Transactional 不生效（代理限制）
配对合适的事务管理器
事务管理器决定事务如何落地，必须与实际数据源匹配：
- JDBC 单数据源 →
DataSourceTransactionManager（最常用） - JPA →
JpaTransactionManager（包装 EntityManagerFactory） - 多数据源 / 分布式 →
JtaTransactionManager（需集成 JTA 实现，如 Atomikos、Narayana） - 注意：一个应用通常只配一个主事务管理器；多数据源需指定
transactionManagerRef
隔离级别与传播行为别硬背，按需设
默认 PROPAGATION_REQUIRED 和 ISOLATION_DEFAULT 覆盖大多数场景。特殊需求才显式设置：
- 读多写少且允许脏读 →
ISOLATION_READ_UNCOMMITTED（极少用） - 防止幻读、需强一致性 →
ISOLATION_SERIALIZABLE（性能差，慎用） - 嵌套调用不希望受外层事务影响 →
PROPAGATION_REQUIRES_NEW（新开事务，挂起旧事务） - 只读操作建议加
readOnly = true，部分数据库（如 MySQL）会优化执行计划
事务失效的常见坑点
配置没错，但事务不生效？多半是运行时逻辑问题：
- 异常被 catch 吞掉，未抛出（@Transactional 默认只对 unchecked Exception 回滚）
- 手动捕获异常后没主动
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() - 异步方法（@Async）独立线程，不在原事务上下文中
- 事务方法调用本类其他方法（无代理介入，事务不生效）
- 数据库引擎不支持事务（如 MySQL 的 MyISAM 表）
事务不是开关，是契约。配对管理器、写对注解、理清调用链、验证回滚效果——四步到位，才算真正“配好”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
