为何@Transactional仅对非受检异常执行回滚？

设计思路 #

• 紧扣Java异常体系的语义划分：Java里的非受检异常（RuntimeException、Error）说白了就是程序无法预见或修复的致命错误——比如空指针、内存溢出、数组越界，这些都是代码逻辑漏洞或者系统级故障，一旦发生意味着当前业务流程已经完全失控，必须终止并回滚事务来保证数据一致性。
• 把事务控制权还给开发者：受检异常（比如SQLException、IOException这类）是Java设计出来让开发者显式处理的预期异常，这类异常通常对应业务场景里的可预见情况——比如用户输入格式错误、资源暂时不可用，框架默认不回滚，就是让开发者根据业务需求自行决定：是回滚，还是记录异常后继续执行后续逻辑。

为何默认不针对所有异常回滚 #

• 业务场景需要灵活决策：举个例子，电商系统里创建订单后调用第三方支付接口，如果抛出了受检的PaymentTimeoutException，这时候可能不需要回滚已经创建的订单，而是把订单标记为“支付超时”，让用户后续重新发起支付。如果默认对所有异常回滚，就会直接删除订单记录，完全违背业务逻辑。
• 遵循Java异常设计的初衷：受检异常的存在就是要求开发者主动处理，框架默认不回滚，是尊重这种设计——开发者既然已经显式捕获或声明了受检异常，就该由你自己决定事务的走向，而不是框架强制替你做回滚的决定。
• 避免不必要的过度回滚：如果所有异常都触发回滚，会导致一些本可以通过业务逻辑修复的场景被强制回滚，反而引发更多数据一致性问题。比如读取配置文件时抛出IOException，这时候可能只需要记录日志、使用默认配置，不需要回滚之前已经完成的数据库操作。

要是你需要让受检异常也触发回滚，直接用@Transactional(rollbackFor = Exception.class)或者指定具体异常类就行，框架早就留好这种灵活配置的入口了。

内容的提问来源于stack exchange，提问作者Toro Boro