1. 为什么@Transactional注解会坑到你？
第一次在Spring项目里用@Transactional注解时，我天真地以为只要简单加个注解就能保证数据库操作的原子性。直到线上出现数据不一致，查了三天日志才发现：这个看似简单的注解背后藏着至少7个容易踩中的陷阱。
Spring的事务管理本质上是通过AOP代理实现的。当你调用一个被@Transactional标记的方法时，实际上调用的是Spring生成的代理对象。这个代理对象会在方法执行前开启事务，在方法结束后根据情况提交或回滚。听起来很完美？问题就出在这个"看似"上。
2. 事务失效的六大经典场景
2.1 自调用问题
这是最常见的坑。当你在同一个类中，方法A调用方法B，即使方法B有@Transactional注解，事务也不会生效。因为这种调用绕过了Spring的代理机制。
java复制@Service
public class OrderService {
// 这个方法的事务会失效！
public void createOrder(Order order) {
validateOrder(order); // 这里的事务注解无效
saveOrder(order);
}
@Transactional
public void validateOrder(Order order) {
// 验证逻辑...
}
}
解决方法很简单：把事务方法放到另一个类中，或者通过ApplicationContext获取代理对象再调用。
2.2 异常类型不匹配
默认情况下，@Transactional只对RuntimeException和Error进行回滚。如果你抛出了IOException这样的检查异常，事务依然会提交。
java复制@Transactional
public void processFile() throws IOException {
// 如果这里抛出IOException，事务不会回滚！
}
解决方案是明确指定回滚的异常类型：
java复制@Transactional(rollbackFor = Exception.class)
2.3 方法修饰符问题
如果你把@Transactional用在private方法上，事务同样不会生效。因为Spring的代理机制无法代理私有方法。protected方法在CGLIB代理下可以工作，但最好还是统一用public。
2.4 数据库引擎不支持
我曾经花了两个小时排查为什么事务不生效，最后发现测试环境的MySQL表用的是MyISAM引擎...记住：只有InnoDB才支持事务。
2.5 传播行为配置不当
java复制@Transactional(propagation = Propagation.NOT_SUPPORTED)
public void batchProcess() {
// 这个方法会在非事务环境下执行
}
如果你错误地配置了传播行为（比如用了NOT_SUPPORTED），事务自然就不会生效。最常用的还是默认的REQUIRED。
2.6 多数据源未指定
当项目中有多个数据源时，如果不在@Transactional中明确指定使用哪个事务管理器，可能会导致事务不生效：
java复制@Transactional("orderTransactionManager")
public void updateOrder() {
// 明确指定事务管理器
}
3. 那些不太明显但很致命的问题
3.1 事务超时陷阱
java复制@Transactional(timeout = 5)
public void longRunningProcess() {
// 如果执行超过5秒，事务会自动回滚
}
timeout的单位是秒。但要注意：这个超时是从事务开启开始计算的，不是单条SQL的执行时间。而且，只有在创建新事务时才会生效（REQUIRES_NEW）。
3.2 只读事务的误解
java复制@Transactional(readOnly = true)
public BigDecimal calculateTotal() {
// 这里如果执行写操作，在某些数据库上会报错
}
readOnly=true并不只是语义上的提示。某些数据库（如MySQL）会根据这个标记进行优化，如果在这种事务中执行写操作可能会报错。
3.3 事务隔离级别的坑
Spring支持的标准隔离级别有：
- DEFAULT（使用数据库默认）
- READ_UNCOMMITTED
- READ_COMMITTED
- REPEATABLE_READ
- SERIALIZABLE
但Oracle实际上不支持REPEATABLE_READ，如果你强制指定，在Oracle环境下会变成SERIALIZABLE，性能影响很大。
4. 性能优化与最佳实践
4.1 事务粒度控制
不要把整个大方法都包在事务里。事务应该尽可能小，只包含必须原子执行的数据库操作。长时间的事务会占用数据库连接，影响整体性能。
4.2 避免事务中的远程调用
java复制@Transactional
public void processOrder() {
updateInventory(); // 本地数据库操作
callPaymentGateway(); // 远程HTTP调用 - 大忌！
}
远程调用放在事务里是灾难性的设计。如果远程调用超时，会导致整个事务长时间不释放，最终拖垮数据库连接池。
4.3 批量操作的特殊处理
Spring提供了一个特殊的传播行为用于批量操作：
java复制@Transactional(propagation = Propagation.REQUIRES_NEW)
public void processBatchItem(BatchItem item) {
// 每个批次项在独立事务中处理
}
这样即使某个批次项失败，也不会影响其他项的处理。
5. 调试与问题排查技巧
5.1 日志配置
在application.properties中添加：
properties复制logging.level.org.springframework.transaction.interceptor=TRACE
logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManager=DEBUG
这样可以看到事务开启、提交、回滚的详细日志。
5.2 运行时检查
可以通过代码检查当前是否在事务中：
java复制TransactionSynchronizationManager.isActualTransactionActive()
5.3 测试策略
一定要为事务方法编写测试，特别是验证异常场景下是否真的回滚了。可以用这个模式：
java复制@Test
public void testTransactionRollback() {
try {
service.methodThatShouldFail();
fail("Expected exception");
} catch (Exception e) {
// 验证数据库状态确实回滚了
}
}
6. Spring Boot中的增强配置
在Spring Boot中，可以在application.properties中配置全局事务属性：
properties复制spring.transaction.default-timeout=30 # 默认超时30秒
spring.transaction.rollback-on-commit-failure=true # 提交失败时回滚
7. 新版本Spring的变化
从Spring 5.3开始，@Transactional的proxyTargetClass默认值从false改为了true，意味着默认使用CGLIB代理而不是JDK动态代理。这解决了一些继承相关的问题，但也可能影响某些特殊场景下的行为。
如果你需要保持旧的行为，可以显式配置：
java复制@EnableTransactionManagement(proxyTargetClass = false)
8. 实际案例：电商订单系统
假设我们有一个电商订单创建流程：
java复制@Transactional
public Order createOrder(OrderRequest request) {
// 1. 扣减库存
inventoryService.reduceStock(request.getItems());
// 2. 创建订单
Order order = buildOrder(request);
orderRepository.save(order);
// 3. 生成支付单
Payment payment = paymentService.createPayment(order);
// 4. 发送创建事件
eventPublisher.publishEvent(new OrderCreatedEvent(order));
return order;
}
这个设计至少有3个问题：
- 远程支付调用放在事务内（支付网关可能超时）
- 事件发布在事务内（如果事件监听器执行时间长会阻塞事务）
- 整个方法耗时可能过长
改进方案：
java复制public Order createOrder(OrderRequest request) {
// 第一阶段：准备数据（非事务）
Order order = buildOrder(request);
Payment payment = buildPayment(order);
// 第二阶段：核心事务操作
transactionalCreate(order, request.getItems());
// 第三阶段：后续处理（非事务）
paymentService.processPayment(payment);
eventPublisher.publishEvent(new OrderCreatedEvent(order));
return order;
}
@Transactional
protected void transactionalCreate(Order order, List<Item> items) {
inventoryService.reduceStock(items);
orderRepository.save(order);
}
9. 高级话题：分布式事务
对于跨服务的分布式事务，@Transactional就力不从心了。这时可以考虑：
- 最终一致性模式（事件驱动）
- Seata等分布式事务框架
- Saga模式
但记住：分布式事务能不用就不用，设计上尽量避免。