spring默认仅对runtimeexception及其子类和error自动回滚，对ioexception等检查异常不回滚，需通过rollbackfor显式指定；事务生效还需满足方法为public、避免同类调用、数据库支持事务且异常不被静默捕获。

Java 中通过异常触发事务回滚，是保障业务数据一致性的核心手段。关键不在于“抛异常”本身，而在于异常如何被事务管理器识别、捕获，并驱动数据库撤销已执行操作。实际落地需结合框架机制、异常类型和调用方式综合设计。

Spring 默认只对运行时异常自动回滚

Spring 的 @Transactional 注解默认仅在抛出 RuntimeException 及其子类（如 IllegalArgumentException、NullPointerException、IllegalStateException）时触发回滚。这是最常用也最安全的配置方式。

• 业务校验失败（如金额为负、库存不足）应主动抛出运行时异常，例如 throw new IllegalArgumentException("订单金额不能为零")
• 数据库主键冲突、唯一索引违例等会由 JDBC 抛出 SQLIntegrityConstraintViolationException（继承自 RuntimeException），天然触发回滚
• 若方法内用 try-catch 吞掉运行时异常且未重新抛出，事务将无法感知失败，导致“假成功”

检查异常需显式声明才回滚

IOException、SQLException 等检查异常（checked exception）默认不会导致 Spring 回滚。若业务逻辑中必须抛出这类异常且希望事务失效，必须在注解中明确指定：

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 写法：@Transactional(rollbackFor = SQLException.class) 或 @Transactional(rollbackFor = Exception.class)
• 典型场景：文件解析服务中读取 Excel 失败（IOException）、调用外部 HTTP 接口超时后需撤回本地入库操作
• 注意：rollbackFor 指定的是“向上匹配的异常类型”，不是必须精确等于抛出的异常类

确保事务能真正生效的四个前提

即使加了 @Transactional，以下情况会导致事务失效，回滚机制形同虚设：

• 方法必须是 public 的——private/protected 方法加注解无效
• 不能在同一个类中直接调用带事务的方法（即“同类调用”），否则绕过 Spring 代理，事务不生效
• 数据库连接必须支持事务（如 MySQL 的 InnoDB 引擎），MyISAM 不支持事务回滚
• 事务方法内不能手动捕获异常后静默处理（如 catch (Exception e) { log.error(...); }），必须让异常穿透出去或显式调用 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()

分布式或多数据源场景需补偿而非强回滚

单体应用可用本地事务兜底，但微服务间跨库、跨服务的操作无法依赖数据库级回滚。此时应转向最终一致性方案：

• 使用 Saga 模式：把转账拆成“扣款→发消息→充值→确认”，每步失败则执行反向操作（退款）
• 引入 事务消息（如 RocketMQ 事务消息）：先发“半消息”，本地事务成功后再提交，失败则回查并回滚
• 所有关键步骤必须具备 幂等性 和 可补偿性，比如用唯一业务 ID 防重，用状态机记录执行进度

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南