退款需保证多表操作原子性，应使用Spring声明式事务（@Transactional），确保操作在同事务上下文、单数据源InnoDB表、抛出RuntimeException或显式配置rollbackFor，跨库则用Seata或最终一致性方案。
退款流程中涉及多表操作（比如更新订单状态、扣减库存、生成退款单、修改账户余额等），一旦某个环节失败，必须整体回滚，否则数据会不一致。Java 中最常用的是 Spring 的声明式事务（@Transactional），它能自动管理多表操作的原子性，前提是满足几个关键条件。
确保所有操作在同一个事务上下文中
Spring 事务基于代理机制，只有被 Spring 管理的 Bean 内部调用 @Transactional 方法时，事务才生效。常见错误是：
- 把事务方法写在工具类或普通 new 出来的对象里——事务不生效
- 同类中非事务方法直接调用事务方法（内部调用绕过代理）——事务失效
- 使用了异步（
@Async）、线程池、定时任务等，未手动传播事务上下文
✅ 正确做法：退款逻辑封装在 Service 层的 public 方法中，由 Controller 调用；若需跨线程，用 TransactionSynchronizationManager 手动绑定，或改用消息队列+补偿机制。
数据库表必须支持事务（InnoDB）且在同一数据源
MySQL 默认 MyISAM 不支持事务，务必确认所有相关表引擎为 InnoDB：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
如果退款涉及多个数据库（如订单库 + 用户库 + 支付库），Spring 原生 @Transactional 无法跨库回滚，此时需考虑：
- 业务上尽量收敛到单库（推荐）
- 使用 Seata、Atomikos 等分布式事务框架
- 采用最终一致性：本地事务 + 可靠消息 + 补偿接口（如“退款失败后自动触发冲正”）
异常必须抛出才能触发回滚（默认只对 RuntimeException 回滚）
Spring 默认只对未检查异常（RuntimeException 及其子类）和 Error 回滚，对 Exception（如 IOException、自定义业务异常）不会回滚：
- 要么让自定义异常继承
RuntimeException - 要么显式配置：
@Transactional(rollbackFor = BusinessException.class) - 避免
try-catch吞掉异常却不重新抛出——事务将正常提交
例如：
@Transactional(rollbackFor = Exception.class)public void processRefund(Long orderId) {
// 更新订单状态
orderMapper.updateStatus(orderId, "REFUNDED");
// 扣减库存（可能抛出 StockNotEnoughException）
inventoryService.deduct(orderId);
// 生成退款记录
refundMapper.insert(new Refund(...));
}
注意事务传播行为与嵌套调用
如果退款方法中调用了另一个已标注 @Transactional 的方法（如“记录操作日志”），要小心传播行为：
-
REQUIRED（默认）：加入当前事务，适合大多数场景 -
REQUIRES_NEW：挂起当前事务，开新事务——日志写入失败不应导致退款主流程回滚，可设为此模式 - 避免
NEVER或NOT_SUPPORTED，它们会脱离事务上下文
例如日志记录独立于退款事务：
@Transactional(propagation = Propagation.REQUIRES_NEW)public void logRefundAction(Long orderId, String remark) {
logMapper.insert(...);
}
