业务回滚是事务失效时的主动补偿机制，需在编码初期设计可逆操作、记录上下文、封装幂等补偿方法，并按逆序执行带异常隔离的状态化补偿链。

业务回滚不是数据库事务的替代品，而是在无法使用事务（如跨服务、异步调用、部分资源不支持事务）时，靠代码主动补偿来维持逻辑一致性。核心思路是：在 catch 块中识别已成功执行的副作用，并按逆序逐一手动清理或反向操作。

明确哪些操作需要“可逆”设计

不是所有操作都能回滚，必须从编码初期就考虑补偿能力：

• 写数据库前，记录关键上下文（如生成的订单号、扣减前的账户余额），便于后续查询状态或构造反向SQL
• 调用外部HTTP接口时，保留请求参数和响应结果；若对方提供撤销接口（如“取消订单”），务必封装成可重试的补偿方法
• 发消息到MQ后，不能直接删除，而是发送“业务撤回”消息，由下游消费方自行处理回退逻辑
• 文件上传、缓存写入等本地资源操作，需配套实现删除/失效方法，并确保路径、key可追溯

在 catch 中组织有序的补偿链

补偿顺序必须与原操作相反，避免因依赖未清理导致失败：

• 假设流程为：① 扣库存 → ② 创建订单 → ③ 发通知。异常发生在第③步，则补偿应先尝试撤回通知（如有）、再删除订单、最后恢复库存
• 每个补偿步骤都应独立 try-catch，防止一个失败阻断后续；失败项记日志并告警，供人工介入或定时任务重试
• 建议将补偿动作封装为带返回值的方法（如 boolean rollbackInventory(String orderId)），便于判断是否成功并决定是否继续

用状态机+幂等性降低补偿复杂度

单纯依赖 try-catch 容易遗漏边界，配合轻量状态管理更可靠：

• 在主表加字段如 status（pending/confirmed/rollbacked）和 last_updated，每次关键操作更新状态
• catch 中不直接执行清理，而是先更新状态为 “rollbacking”，再触发补偿；若补偿失败，状态卡住，可被监控系统捕获
• 所有补偿操作必须幂等：重复调用不影响最终结果（例如恢复库存用“+原始扣减量”而非“设为原始值”，避免并发覆盖）

避免常见陷阱

手动回滚容易踩坑，需特别注意：

• 不要在 finally 里做补偿：finally 总会执行，包括正常流程结束时，会导致误清理
• 不依赖不可靠的“查最新状态”：比如补偿时查订单状态再决定是否删单，可能因延迟读取到旧值；应以本地记录的操作事实为准
• 跨库/跨服务的补偿要有超时和重试机制：网络抖动可能导致补偿失败，需配指数退避重试 + 最大次数限制
• 日志必须包含完整上下文：订单ID、操作步骤、补偿结果、异常堆栈，否则问题定位成本极高