Spring 允许在同一个 Bean 类中定义多个 @Transactional 方法，它们各自独立开启、提交或回滚事务；但需注意：若这些方法被非事务上下文调用（如普通业务方法顺序调用），则彼此事务隔离，前一个方法的提交不会因后一个失败而回滚。
spring 中单个类能否定义多个 @transactional 方法？spring 允许在同一个 bean 类中定义多个 `@transactional` 方法，它们各自独立开启、提交或回滚事务；但需注意：若这些方法被非事务上下文调用（如普通业务方法顺序调用），则彼此事务隔离，前一个方法的提交不会因后一个失败而回滚。
在 Spring 的声明式事务管理中，@Transactional 是基于代理（Proxy）机制实现的。这意味着事务行为仅在通过 Spring 容器注入的代理对象调用 public 方法时生效。因此，关于你的两个核心问题，我们逐一解析：
✅ 多个 @Transactional 方法可共存于同一类中
是的，完全支持。只要方法为 public 且由 Spring 代理调用，每个 @Transactional 方法都会启动独立的事务上下文。例如：
@Service
public class AccountService {
@Transactional
public void transferFromAtoB(BigDecimal amount) {
// 扣减账户 A（事务1开始）
updateBalance("A", amount.negate());
// 账户 B 增加（同属事务1）
updateBalance("B", amount);
// ✅ 若此处抛出未检查异常，整个 transferFromAtoB 回滚
}
@Transactional(rollbackFor = InsufficientBalanceException.class)
public void withdraw(String account, BigDecimal amount) throws InsufficientBalanceException {
if (getBalance(account).compareTo(amount) < 0) {
throw new InsufficientBalanceException();
}
updateBalance(account, amount.negate());
// ✅ 自定义异常也会触发回滚（因 rollbackFor 显式指定）
}
}⚠️ 注意：@Transactional 注解对 private、protected 或包级访问方法无效——Spring 无法为其生成代理增强逻辑。
❗ 调用方式决定事务是否“联动”
关键点在于：事务边界由方法入口决定，而非调用链路。回到你示例中的 class B：
@Service
public class BatchProcessor {
private final AccountService accountService;
public BatchProcessor(AccountService accountService) {
this.accountService = accountService;
}
// ❌ 非事务方法：doSomeStuff() 无 @Transactional
public void doSomeStuff() {
accountService.transferFromAtoB(new BigDecimal("100")); // 事务1：成功即提交
accountService.withdraw("C", new BigDecimal("50")); // 事务2：独立执行，失败不回滚事务1
}
}此时：
- transferFromAtoB() 执行完毕 → 事务1 立即提交；
- 即使 withdraw() 后续抛出异常并回滚事务2，事务1的修改不可逆；
- 若需二者原子性（即“全成功或全失败”），必须将 doSomeStuff() 本身标记为 @Transactional：
@Transactional
public void doSomeStuff() {
accountService.transferFromAtoB(new BigDecimal("100"));
accountService.withdraw("C", new BigDecimal("50"));
// ✅ 现在两者运行在同一事务中：任一失败 → 全部回滚
}? 类访问修饰符要求：仅方法需 public，类无需 public
- ✅ @Transactional 方法必须是 public（Spring AOP 代理限制）；
- ✅ 类本身可以是 package-private（默认访问级别）、protected 甚至 private（若为嵌套类），只要它能被 Spring 容器管理（如通过 @Service、@Component 等注解注册为 Bean）即可；
- ❌ 但实践中，建议将服务类声明为 public ——这符合 Java 封装规范，也避免因包访问限制导致测试或集成困难。
? 总结与最佳实践
| 项目 | 要求 | 说明 |
|---|---|---|
| 方法可见性 | 必须 public | 否则代理无法拦截，事务失效 |
| 类可见性 | 无强制要求 | 推荐 public，便于维护与测试 |
| 多事务共存 | ✅ 支持 | 每个 @Transactional 方法拥有独立事务生命周期 |
| 事务传播 | 关注 propagation 属性 | 默认 REQUIRED，嵌套调用时复用当前事务；如需新事务，设为 REQUIRES_NEW |
| 异常回滚 | 默认仅对 RuntimeException 及其子类回滚 | 如需检查型异常触发回滚，使用 rollbackFor = {XXXException.class} |
? 提示：可通过开启 @EnableTransactionManagement(proxyTargetClass = true) 启用 CGLIB 代理，支持类内 this.method() 调用事务方法（但仍推荐拆分职责、避免自我调用）。
合理设计事务边界，是保障数据一致性的基石——不要依赖“顺序调用=事务连贯”，而应显式声明事务作用域。
