工作 6 年，@Transactional 注解用的一塌糊涂！

主要观点总结

本文详细讲述了在使用 @Transactional 注解时可能遇到的各种问题及其解决方案，涵盖了不必要的用法、不生效、不回滚、事务无法捕获的异常、自定义异常范围问题、嵌套事务问题等场景，并提供了具体的代码示例和解决方案，以帮助开发者避免踩坑。

关键观点总结

关键观点1: 不必要的用法

在不需要事务的业务方法上添加 @Transactional 注解是不严谨的，建议去掉，如查询或 HTTP 请求方法。

关键观点2: 不生效

在 private 方法、final 方法、static 方法上添加 @Transactional 注解不会生效，因为这些方法不能被代理，事务管理失效。

关键观点3: 不回滚

在异常处理中，需要确保捕获的异常被重新抛出，以便 Spring 事务能正确回滚。

关键观点4: 事务无法捕获的异常

Spring 默认只回滚 RuntimeException 及其子类，以及 Error 类型的异常。对于其他类型的异常，需要明确指定在 @Transactional 注解的 rollbackFor 参数中。

关键观点5: 自定义异常范围问题

自定义异常类型应继承自 RuntimeException，以确保事务能够捕获并回滚。

文章预览

mall项目实战教程网： macrozheng.com 接手新项目一言难尽，别的不说单单就一个 @Transactional 注解用的一塌糊涂，五花八门的用法，很大部分还失效无法回滚。 有意识的在涉及事务相关方法上加 @Transactional 注解，是个好习惯。不过，很多同学只是下意识地添加这个注解，一旦功能正常运行，很少有人会深入验证异常情况下事务是否能正确回滚。@Transactional 注解虽然用起来简单，但这货总是能在一些你意想不到的情况下失效，防不胜防！ 我把这些事务问题归结成了三类： 不必要 、 不生效 、 不回滚 ，接下用一些demo演示下各自的场景。 不必要 1. 无需事务的业务 在没有事务操作的业务方法上使用 @Transactional 注解，比如：用在仅有查询或者一些 HTTP 请求的方法，虽然加上影响不大，但从编码规范的角度来看还是不够严谨，建议去掉。 @Transactional public S ………………………………