编程式事务适用于动态边界场景，如支付回调、分步操作、嵌套局部事务及跨数据源操作；推荐用TransactionTemplate，注意避免远程调用、吞异常、异步和超时问题。
编程式事务在 Java 业务中不是“要不要用”的问题，而是“在哪用、怎么控、如何稳”的问题。它不替代声明式事务，而是在那些 @Transactional 注解无法覆盖的动态边界场景里，提供精准的手动控制能力。
适合用编程式事务的业务点
当事务逻辑不能静态预设，必须根据运行时条件决定是否提交或回滚时，就该上编程式事务。典型情况包括：
- 支付回调处理：收到第三方通知后，需先校验签名和订单状态，再决定是更新支付成功还是记录异常并回滚
- 分步操作原子性保障：比如电商下单要写订单、写明细、扣库存、发消息，其中某一步失败必须整体回退，且每步可能有独立重试或补偿逻辑
- 嵌套流程中的局部事务：外层方法已带 @Transactional，但内层某段逻辑需要独立事务（如日志落库失败不能影响主流程），这时只能用编程式新开事务
- 跨数据源操作：一个操作涉及 MySQL 和 PostgreSQL，Spring 声明式事务默认只管一个 DataSource，多数据源需手动协调
核心写法：用 TransactionTemplate 最简洁安全
推荐使用 Spring 的 TransactionTemplate，它封装了 PlatformTransactionManager 的底层调用，避免手写 try-catch-rollback 模板代码出错。关键三步：
- 注入 TransactionTemplate（通常通过构造函数）
- 用 execute 方法传入业务逻辑（实现 TransactionCallback 接口或用 lambda）
- 返回值可带结果，异常自动回滚，无需显式 throw
示例代码：
sc-java-to-ts-interface
下载
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
立即学习“Java免费学习笔记（深入）”；
public Order createOrder(Long userId, Long productId) {
return transactionTemplate.execute(status -> {
// 1. 创建订单主表
Order order = new Order(userId, productId);
orderMapper.insert(order);
// 2. 插入明细
OrderItem item = new OrderItem(order.getId(), productId, 1);
orderItemMapper.insert(item);
// 3. 扣库存（失败则整个事务回滚）
boolean deducted = inventoryService.deduct(productId, 1);
if (!deducted) {
throw new IllegalStateException("库存不足");
}
return order; // 成功则自动提交
});
}
注意几个易踩坑细节
写对只是第一步，写稳才是关键：
- 不要在事务块里做远程调用：HTTP 请求、MQ 发送等耗时操作放在事务外，否则拖慢数据库连接、增加超时风险
- 避免在 execute 内部捕获并吞掉异常：一旦 catch 住异常又没 re-throw，事务不会回滚，数据就脏了
- 事务内慎用异步：new Thread 或 @Async 方法会脱离当前事务上下文，导致数据库操作不在事务中
- 超时时间要设合理值：默认 30 秒可能不够，尤其含外部依赖时；可在 TransactionTemplate 构造时 setTimeout(60)
进阶：结合模板方法统一事务入口
如果多个业务方法都需要类似“查→校验→写→发消息”结构，可抽象为模板方法，把事务控制收拢到父类：
- 定义 abstract protected void doInTransaction() 方法，子类只填业务逻辑
- 父类的 public final T executeWithTx() 统一调用 transactionTemplate.execute()
- 这样既保持编程式事务的灵活性，又消除重复代码，还利于统一加监控、打日志、埋点
