try-catch 不实现分布式事务补偿，而是保障补偿逻辑可靠触发：捕获异常后执行cancel、重试注册、写补偿任务表或回滚本地事务，避免补偿丢失。
Java 中的 try-catch 本身不直接实现分布式事务补偿，但它在本地事务控制和补偿逻辑的异常捕获、流程转向中起关键支撑作用。真正承担补偿职责的是业务层设计（如 TCC 的 Cancel、Saga 的补偿动作），而 try-catch 是保障这些补偿动作被正确触发、避免异常穿透、防止补偿丢失的“守门人”。
try-catch 在补偿触发环节的必要性
在分布式事务中，本地操作（如扣减库存、生成订单）常需与补偿注册或消息发送绑定。若本地事务成功但后续补偿注册失败，系统将失去回滚能力。此时 try-catch 可拦截异常，主动调用 Cancel 或重试补偿注册。
- Try 块中执行本地预留操作（如更新库存状态为“预占”）
- Catch 块中立即执行本地回滚（如将状态还原为“可用”），并记录日志供人工干预
- 避免因网络超时、序列化失败等非业务异常导致补偿链断裂
配合 TCC 模式实现可靠 Cancel 调用
TCC 要求 Cancel 阶段幂等且必须执行。但远程 Cancel 调用可能因网络抖动失败，仅靠重试不够——需用 try-catch 封装调用，并结合状态机判断是否需降级处理。
- Confirm 失败后进入 Cancel 流程，用 try-catch 包裹 Cancel 接口调用
- 捕获 ConnectException、TimeoutException 时，不抛出，而是写入补偿任务表，由后台定时器驱动重试
- 捕获业务异常（如库存已释放）则视为 Cancel 成功，无需重复执行
保障消息事务中本地事务与消息的一致性
基于消息队列的最终一致性方案，常采用“本地消息表”模式：先在本地事务中写业务数据 + 写消息记录，再异步发消息。这个本地事务必须用 try-catch 守护。
- try 块内完成数据库 insert（业务表 + 消息表）
- catch 块中回滚整个本地事务，确保不会出现“业务成功但消息丢失”
- finally 不用于事务回滚（应由 catch 显式 rollback），但可用于释放连接等资源
常见误用与规避建议
很多人把 try-catch 当作兜底方案，反而掩盖了补偿设计缺陷。以下做法需避免：
- 空 catch 块：捕获异常后不做任何处理或记录，导致补偿失败无声无息
- 在 finally 中执行 Confirm/Cancel：finally 会在 return 之后执行，可能造成重复提交或状态错乱
- 只 catch RuntimeException：忽略 SQLException、IOException 等受检异常，使补偿流程在 IO 故障时中断
- 未对补偿操作做幂等校验：即使 try-catch 捕获了异常并重试 Cancel，重复执行仍可能引发数据异常
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
