业务层事务边界规范的核心是精准匹配业务语义：以用例为单位设事务起点，按协作关系选传播行为，显式控制回滚条件，规避代理失效陷阱，确保每次@transactional都体现明确的业务契约。

业务层事务边界的规范，核心是让事务范围精准匹配业务语义——既不能过大导致锁竞争和长事务，也不能过小破坏业务原子性。关键不在“加@Transactional”，而在“加在哪儿”和“怎么配”。

一、以用例为单位划定事务起点

事务应始于一个完整业务用例的入口方法，通常是 Service 层的公有方法，且该方法代表一个不可再分的业务动作。例如“创建订单”“提交退款申请”“批量审核工单”。

• 避免在 DAO 层或私有方法上标注 @Transactional，这会割裂业务语义
• 禁止在 Controller 层开启事务（违反分层职责），也不应在工具类或通用方法中隐式开启
• 若一个用例含多个子操作（如下单+扣库存+发消息），它们应由同一个事务管理，除非明确需要解耦（见下条）

二、按协作关系选择传播行为

当业务方法间存在调用链时，传播行为决定事务上下文如何流转。默认 REQUIRED 多数场景够用，但需主动甄别例外：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 子操作必须独立成功/失败（如记录操作日志、发送异步通知）→ 用 REQUIRES_NEW，确保它不拖垮主事务
• 子操作只是主流程的一部分，失败即主流程失败（如校验库存后创建订单）→ 保持 REQUIRED，共享同一事务
• 纯查询类方法（如获取用户配置）→ 可选 SUPPORTS，有事务则加入，无则非事务执行，减少连接占用
• 绝不使用 MANDATORY 除非你100%确定调用方一定在事务中——极易引发运行时异常

三、显式控制回滚条件与异常设计

Spring 默认只对 RuntimeException 及其子类回滚，而业务异常（如 InsufficientBalanceException）通常是 checked 异常，需显式声明：

• 所有自定义业务异常应继承 RuntimeException，或在 @Transactional 中指定 rollbackFor = BusinessException.class
• 对外接口抛出的异常需统一包装，但事务回滚逻辑必须在服务层完成，不能等到 Controller 才处理
• 严禁在事务方法内 catch 并吞掉异常（尤其是未 re-throw），否则事务不会回滚，数据状态将不一致

四、规避代理失效与边界陷阱

@Transactional 依赖 Spring AOP 代理生效，以下情况会导致事务失效：

• 同类内方法调用（this.method()）→ 调用未经过代理，事务注解不生效。应拆分为不同 Bean 或改用 TransactionTemplate
• 非 public 方法上使用 @Transactional → Spring 代理不拦截，直接忽略
• 异步方法（@Async）默认脱离当前事务上下文 → 如需事务，须显式传递 TransactionStatus 或改用 REQUIRES_NEW
• 事务方法内启动新线程 → 新线程不继承事务上下文，数据库操作将走自动提交模式

事务边界不是技术开关，而是业务契约的代码映射。每一次 @Transactional 的添加，都应能回答：这个操作失败时，哪些数据必须一起撤销？哪些可以单独保留？厘清这点，边界自然清晰。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南