泛型方法不控制事务回滚，真正决定回滚的是Spring事务拦截器根据@Transactional的rollbackFor配置和抛出异常类型判断；泛型仅在编译期强化异常表达与传递，确保异常原样上抛供事务框架识别。
泛型方法本身不直接控制事务回滚，它不能替代 @Transactional 的异常策略配置。真正决定事务是否回滚的，是 Spring 事务拦截器（TransactionInterceptor）在方法执行后，根据抛出的异常类型和 @Transactional 注解中 rollbackFor 或 noRollbackFor 的声明来判断的。泛型方法的作用，是在编译期强化异常类型的表达与传递，避免因类型擦除或误捕获导致异常被“吞掉”或转为非预期类型，从而间接保障事务框架能拿到原始、明确的异常实例。
泛型方法需配合 @Transactional 显式声明回滚规则
Spring 默认只对 RuntimeException 及其子类自动回滚。如果泛型方法内部抛出的是检查型异常（如 IOException、自定义 BusinessException），而你又希望它触发回滚，就必须在方法上显式标注：
-
@Transactional(rollbackFor = BusinessException.class)—— 精确指定某类业务异常必须回滚 -
@Transactional(rollbackFor = Exception.class)—— 覆盖所有异常（慎用，可能掩盖本应被捕获处理的受检异常） - 避免仅依赖泛型形参（如
<E extends Throwable>）代替注解配置，Spring 不解析泛型约束作为回滚依据
用泛型约束统一异常出口，防止 try-catch 意外吞异常
常见错误：在泛型服务方法里用 try-catch 捕获异常后仅打日志、返回错误码，却未重新抛出 —— 这会导致事务拦截器收不到异常，事务正常提交。
正确做法是借助泛型让异常“穿透”出去：
- 定义泛型工具方法，强制要求调用方处理或声明异常：
public <T, E extends Exception> T executeWithThrow(Supplier<T> action, Class<E> exType) throws E - 在业务方法中调用时，保持异常原始类型不变：
return executeWithThrow(() -> userMapper.insert(user), BusinessException.class); - 这样既利用泛型明确了异常契约，又确保异常原样向上抛给事务拦截器
避免泛型擦除导致的异常类型失真
Java 泛型在运行时被擦除，throw new E() 是非法的。若试图通过泛型参数构造并抛出异常，容易写出如下错误代码：
-
<E extends Exception> void doWork() { throw (E) new RuntimeException(); }—— 强制转型不安全，可能抛ClassCastException - 正确方式是使用工厂函数或预定义异常实例，例如：
private final BusinessException validationFailed = new BusinessException("validation failed");<br>public <T> T save(T entity) { if (invalid(entity)) throw validationFailed; ... } - 确保最终抛出的异常类型与
@Transactional.rollbackFor声明的类型完全匹配（含包路径），否则回滚不会生效
事务传播行为影响泛型方法的异常可见性
当泛型方法被嵌套在另一个 @Transactional 方法中时，传播行为会改变异常的传递路径：
-
Propagation.REQUIRED（默认）：内层方法异常会向上传播，外层事务感知并回滚 -
Propagation.REQUIRES_NEW：内层是独立事务，即使它抛出BusinessException并回滚，外层事务仍可正常提交 —— 此时需确认你是否真需要这种隔离 - 泛型方法若位于
REQUIRES_NEW事务中，它的异常对调用方仍是可见的，但事务回滚效果不连带外层，这点与泛型无关，但常被忽略
