TransactionTemplate 的核心是将事务控制权从方法级收归代码内部，精准圈定需原子执行的DB操作段，配合动态事务属性、数据库锁机制及提交后异步处理，弥补@Transactional不足。
Java 中用 TransactionTemplate 处理复杂业务，核心是把事务控制权从方法边界收回到代码内部——不是“整个方法要不要事务”，而是“哪几行 DB 操作必须原子执行”。它不替代 @Transactional，而是在注解力所不及的地方补位。
明确事务边界：只包裹真正需要一致性的操作
复杂业务常混杂数据库写入、HTTP 调用、文件上传、缓存更新等。TransactionTemplate 的价值在于精准圈定其中的“关键数据变更段”：
- 先完成所有非 DB 操作：参数校验、OSS 上传、远程接口调用、DTO 转换
- 再用 transactionTemplate.execute() 包裹实际的 DAO 操作（如 updateById、insertBatch、deleteByCondition）
- 事务块内避免日志打印、循环计算、消息发送等无关逻辑，防止锁持有时间被意外拉长
动态配置事务属性：按场景调整行为
不同业务对事务的要求不同，不能一套配置走天下：
- 高并发库存扣减：设 setTimeout(3) 防止卡死；用 ISOLATION_READ_COMMITTED 减少间隙锁
- 审计日志记录：用 PROPAGATION_REQUIRES_NEW 确保即使主事务回滚，日志仍能落库
- 读多写少报表导出：设 setReadOnly(true) 让数据库优化执行计划
- 默认的 PROPAGATION_REQUIRED 已足够多数嵌套调用场景，无需额外设置
配合数据库锁机制：解决查-改分离问题
单纯靠 TransactionTemplate 无法规避“先查后改”导致的超卖或重复处理。必须和数据库原生命令协同：
立即学习“Java免费学习笔记（深入）”；
- 在 execute 回调里，查询语句显式加锁：SELECT * FROM stock WHERE id = ? FOR UPDATE
- 或使用 JPA 的 @Lock(LockModeType.PESSIMISTIC_WRITE) 注解
- 若业务允许，改用乐观锁（version 字段 + CAS 更新），降低数据库锁开销
- 避免在事务外查一次、事务内再查一次的两段式逻辑
善用回调与异常处理：提交后动作不进事务
事务成功后的衍生操作（如发 MQ、刷新缓存、通知下游），绝不能放在 execute 回调里同步执行：
- 用 TransactionSynchronizationManager.registerSynchronization() 注册监听器
- 在 afterCommit() 方法中触发异步任务，确保不延长锁持有时间
- 异常处理要干净：不要在回调里 try-catch 吞掉异常，否则事务可能意外提交
- 必要时主动调用 status.setRollbackOnly() 标记回滚，比如校验失败但不想抛异常
