java编程式事务通过transactiontemplate和保存点实现比声明式更细的粒度控制，支持代码块级事务与局部回滚，适用于跨服务、多数据源等复杂场景。
Java 中编程式事务能实现比声明式更细的粒度控制，核心在于把事务边界从“整个方法”下沉到“某几行代码”，甚至支持同一事务内局部回滚。关键不靠黑魔法，而在于选对工具、设好边界、用好保存点。
用 TransactionTemplate 管理代码块级事务
TransactionTemplate 是 Spring 封装好的轻量级编程式事务工具，无需手动开启/提交/回滚，专注业务逻辑本身。
- 注入后直接调用 execute()，传入 TransactionCallback 回调，在 doInTransaction() 里写需要事务保护的代码
- 默认只对 RuntimeException 回滚，如需对特定检查异常也回滚，可自定义 TransactionDefinition 设置 rollbackOn()
- 事务属性（传播行为、隔离级别、超时）可在构造时传入，灵活适配不同场景，比如读操作用 SUPPORTS，写操作用 REQUIRED
在单个事务内实现“局部回滚”
事务本身是原子的，但可通过 JDBC Savepoint 在同一个事务中划出可回退的子区域，模拟部分成功、部分失败的效果。
- 在可能出错的操作前调用 status.createSavepoint() 创建保存点，返回唯一标识 sp
- 若该段逻辑抛异常，捕获后调用 status.rollbackToSavepoint(sp)，仅回滚这部分，前面已执行的仍有效
- 若成功执行，则调用 status.releaseSavepoint(sp) 释放保存点，避免资源泄漏
- 注意：Savepoint 仅在当前事务内有效，且依赖数据库驱动支持（MySQL、PostgreSQL、Oracle 均支持）
拆分事务边界比硬套保存点更健壮
频繁依赖 Savepoint 往往说明事务设计过重——本不该强一致的操作被强行绑在一起。
- 例如订单创建 + 发送站内信 + 更新用户积分：只有订单必须强一致，后两者失败可异步重试或补偿，应拆为独立事务
- 用 @Transactional(propagation = Propagation.REQUIRES_NEW) 启动新事务，或通过 ApplicationEvent + @EventListener 实现解耦
- 真正需要“精准控制”的地方，往往是跨服务、跨数据源、或含外部调用的混合操作，这时编程式事务配合状态机或 Saga 模式更合适
避开常见陷阱
编程式事务不是万能胶，用错反而引入隐性风险。
- 不要在循环体内反复调用 execute()，会创建大量小事务，拖慢性能；批量操作优先用批处理+单事务
- TransactionTemplate 默认使用当前线程绑定的事务管理器，多数据源时需明确指定 PlatformTransactionManager Bean
- 避免在非 Spring 管理对象（如 new 出来的类）中使用 transactionTemplate，它无法获取上下文事务资源
- 日志记录、参数校验、缓存更新等非核心 DB 操作，尽量移出事务块，减少锁持有时间
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
