Java中try-catch不是补偿逻辑的实现者，而是保障补偿动作被触发、不丢失的“守门人”；其核心作用是捕获异常后执行Cancel、写补偿任务表或本地回滚，配合状态机、幂等接口与持久化任务实现可靠补偿。
Java 中处理分布式事务的补偿机制，核心不是靠事务本身“自动补偿”，而是靠业务层主动设计 + 异常捕获 + 可靠执行保障。try-catch 不是补偿逻辑的实现者，而是补偿动作能被触发、不丢失的关键守门人。
补偿机制的本质是业务逆向操作
分布式事务无法像单机事务那样靠数据库回滚，所以得靠人工定义“怎么撤回”。比如：
- 订单服务创建了订单，但支付失败 → 订单服务要提供“取消订单”接口
- 库存服务冻结了 10 件商品 → 要提供“解冻库存”接口
- 账户服务预扣了金额 → 要提供“释放预扣金额”接口
这些 Cancel 操作必须幂等、可重入、不依赖外部状态，否则重复执行会引发数据错乱。
try-catch 的真实作用：兜住异常，确保补偿被调用
本地事务成功后，紧接着要发消息、调 Cancel、写任务表——这些步骤都可能失败。try-catch 就是用来拦截这些失败，不让流程中断或静默丢弃：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 在 Confirm 失败后，用 try-catch 包裹 Cancel 调用，捕获网络超时、连接拒绝等异常
- catch 块中不抛异常，而是写入补偿任务表（如 compensation_task 表），标记待重试
- 对业务异常（如“库存已释放”）做语义判断，直接视为 Cancel 成功，避免无效重试
- 绝不在 finally 里执行 Cancel 或 Confirm，防止 return 后二次触发
落地时必须配套的三样东西
光有 try-catch 和 Cancel 接口远远不够，真正可靠的补偿需要：
- 状态机驱动：每个业务操作记录明确状态（如 “created → reserved → confirmed → cancelled”），补偿前先查状态，避免重复或跳步
- 持久化补偿任务：把待执行的 Cancel 请求写进数据库或消息表，由独立定时任务或消息消费者驱动，不依赖原请求链路
- 幂等+重试+监控：Cancel 接口带唯一业务 ID；重试需指数退避；所有补偿失败必须告警，不能只打日志
别踩这几个典型坑
很多团队补偿没效果，问题往往出在细节：
- 空 catch：捕获异常后只写一行 log，没记录、没落库、没告警，等于没补偿
- 只 catch RuntimeException：忽略了 SQLException、IOException 等受检异常，IO 故障时补偿链直接断裂
- Cancel 没校验前置条件：比如库存已归还，还强行解冻，导致负库存
- 把补偿当重试用：重试是正向再试一次，补偿是反向撤销，混用会导致状态混乱
