catch块是业务一致性保障的关键防线，需通过幂等回滚、状态快照+补偿事务、AutoCloseable自动管理及结构化日志监控等手段确保异常后数据可靠。
在Java中，catch块不只是用来“吞掉异常”或简单打印日志的，它往往是业务一致性保障的关键防线。当涉及数据库操作、分布式调用、文件写入或状态变更等复杂流程时，异常发生后必须精准回滚已执行的副作用，否则极易引发数据不一致。核心原则是：回滚动作本身必须幂等、可预测、与正向逻辑解耦，且不能因回滚失败导致主异常被掩盖。
明确回滚边界，避免在catch里堆砌多层逻辑
很多开发者习惯在同一个catch块中依次关闭资源、重置状态、删除临时文件、调用补偿接口……这看似“一气呵成”，实则风险极高：任一回滚步骤失败（如网络超时、权限不足），都会中断后续回滚，甚至覆盖原始异常，使问题难以定位。
- 将回滚操作封装为独立方法，命名体现语义，如
rollbackInventoryReservation()、revertPaymentHold() - 每个回滚方法内部需捕获并记录其子异常，但不抛出——用
log.warn("Failed to rollback X, proceeding...", e)，确保不影响主流程清理 - 按“后执行、先回滚”顺序调用（LIFO），例如：先创建订单 → 再扣库存 → 最后冻结资金，则回滚顺序应为：解冻资金 → 补回库存 → 删除订单草稿
用状态快照代替“硬回滚”，提升可靠性
对于无法原子撤销的操作（如已发HTTP通知、已写MQ消息、已调用第三方API），强行“反向调用”可能失败或不可逆。此时应放弃“还原世界状态”的幻想，转而采用“状态快照 + 补偿事务”策略。
- 在业务开始前，用本地事务或Redis记录关键状态快照，如
"order_123: pre_inventory=50, pre_balance=1000.00" - 异常捕获后，不再尝试调用“减库存接口的加回接口”，而是基于快照发起幂等补偿动作，如发送
CompensateInventoryCommand到队列，由下游服务保证最终一致性 - 快照本身需具备过期机制（如TTL 24h）和清理钩子，防止堆积
利用try-with-resources + 自定义AutoCloseable实现自动回滚
对资源型操作（如临时文件、内存缓存锁、本地事务标记），可设计一个支持“失败自动触发回滚”的AutoCloseable包装器，让JVM帮我们管理清理时机。
立即学习“Java免费学习笔记（深入）”；
- 定义
RollbackScope类，构造时注册成功/失败回调；close()根据内部标志决定执行commit逻辑还是rollback逻辑 - 在业务代码中这样使用：
try (RollbackScope scope = new RollbackScope(this::doCommit, this::doRollback)) { ... } - 即使业务逻辑中途
return或抛出未被捕获的异常，close()仍会被调用，确保回滚不遗漏
日志与监控必须暴露回滚决策依据
生产环境最怕“静默回滚”——系统看似平稳，实则反复补偿却无人知晓。每次回滚动作都应留下可追溯的痕迹。
- 记录结构化日志，包含：业务单号、触发异常类型、回滚操作名、输入参数摘要、执行结果（success/failed）、耗时
- 对高频回滚场景（如库存不足导致的订单取消）单独打标，接入告警系统，避免把“业务规则拒绝”误判为“系统故障”
- 在分布式链路追踪中，将回滚阶段标记为
span.tag("rollback", "true")，与主流程span关联，便于全链路分析
不复杂但容易忽略：回滚不是纠错的终点，而是可观测性与容错设计的起点。写好catch里的回滚，本质是在为系统的确定性兜底。
