在父类方法标注@Transactional作为默认行为是否存在弊端？

父类默认@Transactional的潜在弊端 #

• 不必要的性能开销：如果子类handle()方法不涉及任何数据库操作，继承的事务会额外消耗数据库连接、服务器资源——事务的开启、维护、提交/回滚全是无意义的损耗，拖慢方法执行效率。
• 事务行为不符合业务预期：父类@Transactional用的是默认配置（比如传播行为REQUIRED），如果子类方法需要SUPPORTS、NOT_SUPPORTED这类特殊传播规则，未重写注解会强制沿用父类规则，可能引发事务嵌套错误、事务边界混乱的问题。
• 回滚规则无法自定义：父类默认只对RuntimeException和Error触发回滚，若子类方法需要针对特定受检异常回滚，或排除某些运行时异常的回滚，不重写注解就无法调整，会导致事务回滚逻辑和业务需求冲突。

子类重写@Transactional的可行性 #

你提出的「在方法级别重写@Transactional注解」是完全合理的解决方案，能完美适配场景需求：

• 当子类方法需要事务时：可以直接继承父类默认配置，也可以重写@Transactional并指定readOnly=true、propagation、rollbackFor等属性，精准匹配业务要求。
• 当子类方法不需要事务时：直接标注@Transactional(propagation = Propagation.NOT_SUPPORTED)，明确禁用事务，彻底避免不必要的资源消耗。
• 这种模式既保留了父类提供的默认事务能力，又给子类充足的灵活性去定制事务行为，完全覆盖「方法可能需要/不需要事务、执行不同数据库操作」的场景。

补充：Spring的注解继承规则中，子类重写方法未标注@Transactional时，会继承父类的注解配置；若子类方法标注了@Transactional，则会完全覆盖父类配置，因此重写时要注意完整设置所需属性，避免遗漏必要配置。

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