java事务高级进阶需理解边界、权衡粒度、应对异常；必须显式声明事务管理器，合理配置传播行为、隔离级别、超时及回滚规则，避免代理失效与混用事务模式等常见陷阱。
Java 事务高级进阶不是堆砌配置，而是理解边界、权衡粒度、应对异常。配得对，事务才真正“可靠”；配错了，反而掩盖问题、拖慢性能、甚至引发数据不一致。
事务管理器必须显式声明
Spring 默认不自动装配事务管理器，尤其在多数据源或非默认 DataSource 场景下，@EnableTransactionManagement 只是开关，真正起作用的是 PlatformTransactionManager Bean。
- 单数据源：通常用
DataSourceTransactionManager，需明确注入对应 DataSource - JPA/Hibernate：应使用
JpaTransactionManager，而非 DataSourceTransactionManager（否则 EntityManager 可能脱离事务上下文） - 多数据源：每个事务管理器需命名（如
@Qualifier("orderTxManager")），并在@Transactional中通过transactionManager属性指定
@Transactional 配置不能只写个注解
默认行为（REQUIRED + unchecked 异常回滚）覆盖不了多数业务场景，关键属性必须按需显式设置：
- propagation：跨服务调用时慎用 REQUIRED（可能意外加入外层事务）；读操作建议用 SUPPORTS 或 NOT_SUPPORTED；独立扣减库存等操作可用 REQUIRES_NEW
-
isolation：MySQL 默认 REPEATABLE READ，但高并发查余额场景若需避免幻读，可设为 SERIALIZABLE（代价高）；更常用的是在 SQL 层加
SELECT ... FOR UPDATE - timeout：必须设！防止长事务阻塞连接池和锁资源，建议 5–30 秒，根据操作复杂度分级设定
-
rollbackFor：默认只对 RuntimeException 回滚，业务异常（如
InsufficientBalanceException）必须显式列出
编程式事务要避开常见陷阱
当声明式无法满足（如动态决定是否开启事务、嵌套分支事务），用 TransactionTemplate 更安全，比手动操作 PlatformTransactionManager 直观且不易漏 rollback：
- 不要在 try-catch 中吞掉异常却不调用
txTemplate.execute(...)的回滚逻辑 - 避免在同一个方法内混用声明式与编程式事务——Spring 事务代理可能失效
- TransactionTemplate 默认传播行为是 REQUIRED，如需隔离，需传入自定义
TransactionDefinition
事务失效的典型配置盲区
很多“事务不生效”问题其实源于配置疏忽：
- 类或方法被 final 修饰 → CGLIB 代理失败 → @Transactional 失效
- 事务方法调用本类另一个事务方法（this.xxx()）→ 无代理介入 → 内部调用不走事务切面
- 异步方法（@Async）未配置独立事务管理器 → 默认使用主线程事务上下文（实际无事务）
- 事务方法抛出 checked 异常但未在 rollbackFor 中声明 → 不回滚
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
