spring boot事务能力提升需围绕“能控制、能诊断、能优化”三大目标：一、用h2内存库+spring boot 3.x+jakarta ee配置真实可测环境；二、动手验证嵌套调用失效、异步事务丢失、隔离级别失效三类典型问题；三、通过transactionsynchronizationmanager和actuator直击事务状态本质；四、进阶采用transactiontemplate、自定义platformtransactionmanager及虚拟线程实现可控式事务管理。
Java事务能力提升不是堆砌概念，而是围绕“能控制、能诊断、能优化”三个实际目标来配。
一、环境配置要真实可测
别只写@Transactional就完事。建议用H2内存数据库起步（零部署、启动快），搭配Spring Boot 3.x + Jakarta EE事务API，确保javax.transaction已升级为jakarta.transaction。配置关键点：
-
spring.datasource.url=jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE - 开启事务日志：
logging.level.org.springframework.transaction=DEBUG - 配置
@EnableTransactionManagement(proxyTargetClass = true)，避免CGLIB与JDK代理混淆
二、动手场景必须覆盖三类典型问题
光看传播行为表格没用，得在代码里亲手触发：
-
嵌套调用失效：Service A调用Service B的
@Transactional方法，B加了注解但事务不生效 → 改用TransactionTemplate或调整代理方式 -
异步事务丢失：
@Async方法里加@Transactional→ 会新开线程，事务上下文断开 → 改用TransactionSynchronizationManager手动绑定，或用CompletableFuture.supplyAsync(() -> { ... }, transactionAwareExecutor) -
读已提交失效：MySQL默认是可重复读，但
@Transactional(isolation = Isolation.READ_COMMITTED)设了却没效果 → 检查MySQL服务端隔离级别是否同步（需SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED）
三、调试手段要直击本质
事务出问题，不能只看日志“rollback”字样。重点检查：
-
TransactionSynchronizationManager.isActualTransactionActive()—— 判断当前线程是否有活跃事务 -
TransactionSynchronizationManager.getCurrentTransactionName()—— 查当前事务名，确认是否进入预期方法 - 数据库连接是否复用：开启
spring.datasource.hikari.leak-detection-threshold=60000，防连接未归还导致事务挂起 - 使用Actuator的
/actuator/health?showDetails=true查看事务管理器状态
四、进阶配法：从声明式走向可控式
当业务复杂到注解不够用时，自然过渡：
- 用
TransactionTemplate做局部事务控制（比如循环中单条失败不中断整体） - 自定义
PlatformTransactionManager实现跨数据源路由（如读写分离时写库走主事务，读库走无事务） - 结合虚拟线程：在
try (var executor = Executors.newVirtualThreadPerTaskExecutor())里执行事务性操作，观察载体线程释放时机对事务资源占用的影响
配齐这些，事务就不再是黑盒，而是一个可观察、可干预、可组合的工程能力。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
