抽象类中统一事务边界应采用模板方法模式，定义public final @Transactional模板方法封装事务，子类实现doBusiness()钩子；必须通过Spring代理对象调用，避免this调用导致事务失效，并支持按需自定义回滚策略。
在抽象类中统一事务边界和回滚逻辑，核心是把事务的开启、提交、回滚等生命周期交由模板方法控制，而具体业务操作由子类实现。Java 中最自然的方式是结合 @Transactional 注解 + 模板方法模式，但需注意 Spring 事务代理机制对抽象类方法调用的限制。
用模板方法定义事务骨架（推荐）
抽象类不直接加 @Transactional，而是提供一个被注解的 final 模板方法，强制子类实现业务逻辑钩子：
- 声明一个 public final @Transactional 方法（如 executeInTransaction()），封装事务边界
- 该方法内部调用抽象的 doBusiness() 或 performAction()，由子类实现具体操作
- 异常统一抛出，由 Spring 自动触发回滚（默认对 RuntimeException 及其子类）
避免子类绕过事务（关键细节）
Spring 的 @Transactional 基于代理，若子类直接调用抽象方法（非通过代理对象），事务会失效。因此必须确保：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 调用入口必须是代理对象（如从 Spring 容器获取的 Bean），不能 new 出实例调用
- 模板方法必须是 public 且 final，防止子类覆写破坏事务结构
- 不要在抽象类中用 this.doBusiness() —— 这会绕过代理，应由模板方法内部调用
支持自定义回滚策略（可选增强）
若需按业务类型决定是否回滚，可在模板中接收参数或提取子类配置：
立即学习“Java免费学习笔记（深入）”；
- 模板方法接受 Class extends Throwable>[] rollbackFor 参数，动态指定回滚异常
- 子类实现 getRollbackExceptions() 返回需回滚的异常类型数组，模板中构建 @Transactional(rollbackFor = ...) 的等效逻辑（实际仍靠注解，需配合 AOP 或手动 TransactionTemplate）
- 更稳妥的做法：统一用 TransactionTemplate 手动控制，适合复杂场景（如嵌套事务、多数据源）
配合 TransactionTemplate 实现完全可控（替代方案）
当需要彻底脱离注解限制（比如动态传播行为、运行时决定是否事务），可用 TransactionTemplate：
- 抽象类注入 TransactionTemplate
- 模板方法内调用 template.execute(status -> { ... })
- 子类实现的业务逻辑放在 lambda 或回调中，可显式调用 status.setRollbackOnly()
- 完全规避代理限制，事务控制权100%在代码中
