事务崩了别怪数据库！三大核心要素没掌握才是根本原因

说真的，每次上线修 Bug 遇到"事务失效"这四个字，我都想立马上楼顶冷静一下。数据库被程序员骂了无数次，但不少时候还真不能怪它------大多数雷，都是我们自己埋下的。

上周同事阿伟又一次喊我："快救命！数据库的事务不起作用，全表更新没回滚，库存炸啦！"哈哈，他这口气像极了觉得自己一点问题都没有，锅都是 MySQL 的锅。我淡定问了句："你是不是只知道 commit/rollback，三大要素你搞清楚了没？"

他一脸懵逼："啥三大要素？"------好家伙，这就是故事的开始。

那些年，我们踩过的事务"坑"

其实 Java 世界说到事务，基本都是和 Spring @Transactional 打交道的，我总结了下，大家踩雷最密集的，有这么几个典型瞬间：

隔离级别？"反正默认就行吧"------结果脏读、幻读满天飞。
传播机制？"我外层有@Transactional就行"------结果内层事务意外失效。
回滚机制？"抛了异常不是自动回滚吗？"------结果 checked exception 扑面而来，程序一脸懵。

我问阿伟："你是不是下面这种典型用法？" 他翻出代码，果然如此朴实无华：

java 复制代码

@Transactional
public void updateStock() {
    // ...更新多张表
    if (xxx) {
        throw new Exception("看似会回滚......");
    }
}

槽点来了，所以说"抛异常自动回滚"，你确定吗？其实只有 RuntimeException（也就是未检查异常）才会自动触发 Spring 的回滚逻辑，普通 Exception 可没这待遇。

踩坑瞬间

那天帮阿伟查 Bug，咱们上真家伙：

问题核心1：checked exception
- 他抛的是 Exception（checked），Spring 并不会自动 rollback。
- 解决办法：@Transactional(rollbackFor = Exception.class)
问题核心2：自行catch住例外
- 代码里 try-catch 把所有异常吞了，Spring 当然检测不到异常发生，事务照常提交。
问题核心3：不懂传播机制
- 方法自己调用自己，@Transactional 无效......Spring AOP 懂的都懂。

有图有真相，主要地方关键几行：

java 复制代码

@Transactional(rollbackFor = Exception.class)
public void outerMethod() {
    try {
        innerMethod();
    } catch (Exception e) {
        // 没抛出，没回滚
        log.error("被我 catch 住了");
    }
}

啧啧，各种防不胜防。

经验启示

后来，阿伟终于明白这三大核心要素了：

要素	懒人误区	你该咋搞
隔离级别	"默认就行！"	了解脏读、幻读风险
传播机制	"随便加个注解"	明白 REQUIRED/REQUIRES_NEW 区别
回滚机制	"随便抛个异常"	Runtime、自定 rollbackFor、避免异常被吞

所以别再张口闭口"数据库背锅，MySQL太坑"，其实各种事务悬案，80%是自己代码写崩的。

讲完了，收个尾巴：踩坑不可怕，搞明白才是大佬。下一次，事务失效不要再冤枉你家数据库，先照照镜子想想，是不是自己三大要素没掌握。最后，用一句朋友总结的话："你只要敢乱用@Transactional，坑就会如影随形。"

下班，溜了~