下单扣库存+记日志用requires_new，确保日志失败不影响订单；查询用supports或not_supported避免事务拖慢；发消息用requires_new防主事务干扰；内部调用慎用required，需显式控制传播行为。

面试中被问到事务传播机制，别光背定义，重点是用业务场景讲清楚“为什么用这个传播行为”，以及“不用会出什么问题”。下面几个典型业务场景，直接拿来就能答。

下单扣库存 + 记录日志：用 REQUIRES_NEW

用户下单时要扣减商品库存（需事务保证一致性），同时记录操作日志（如“用户A购买了商品X”）。日志写入失败，不能让整个下单回滚——库存已扣，订单却没生成，数据就错乱了。

• 库存扣减走默认的 REQUIRED（嵌套在主事务里）
• 日志方法上加 @Transactional(propagation = Propagation.REQUIRES_NEW)，开启独立事务
• 这样日志失败只回滚日志，不影响库存和订单；日志成功但下单后续出错，日志也不会被回滚

查询类操作：用 SUPPORTS 或 NOT_SUPPORTED

比如订单详情页要查用户积分、优惠券、物流状态等——这些只是读取，不修改数据。如果当前已有事务（比如正在下单），用 SUPPORTS 可以复用它，省开销；如果明确不想参与任何事务（比如避免长事务拖慢查询），就用 NOT_SUPPORTED，挂起现有事务，以非事务方式执行。

Alibabacloud Sdk Client Initialization For Java

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

下载

• @Transactional(propagation = Propagation.SUPPORTS)：有事务就加入，没事务也不起新事务
• @Transactional(propagation = Propagation.NOT_SUPPORTED)：强制挂起当前事务，纯读操作更轻量
• 避免把只读查询卷进一个耗时的下单事务里，导致事务过长、锁表时间增加

发消息/调外部接口：用 REQUIRES_NEW 或 NEVER

订单创建成功后，要发MQ消息通知风控系统。这个动作不能和订单事务绑死：消息发送失败（比如网络抖动），不能导致订单回滚（用户已经付款成功）；反过来，消息发出去了，但订单因校验失败回滚了，那这条消息就是脏数据。

• 推荐用 REQUIRES_NEW：确保消息发送有自己独立的事务，成功与否不影响主流程
• 极端情况（如要求“绝不允许在事务内发消息”），可用 NEVER，强制检测并抛异常，倒逼开发把发消息逻辑移出事务边界
• 注意：REQUIRES_NEW 启的新事务，无法感知原事务的回滚，所以还需配合本地消息表或事务消息方案来保最终一致性

内部服务调用：慎用 REQUIRED（默认值）

比如 UserService.updateUser() 调用了 AddressService.updateDefaultAddress()。两个方法都加了 @Transactional，默认都是 REQUIRED —— 表面上是“一个事务”，但实际可能因代理失效（this.调用）、异常类型不对（只对 RuntimeException 回滚）、或 catch 住了异常没抛出，导致事务不生效。

• 不是所有“调用带事务的方法”就自动事务传播了，得看是否走 Spring 代理
• 跨 service 调用建议显式标注传播行为，避免依赖默认值带来的隐式耦合
• 如果 AddressService 的更新必须和用户更新强一致，就保持 REQUIRED；如果只是尽力而为，可考虑 REQUIRES_NEW + 重试补偿

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