全局异常处理不负责重试或补偿，仅统一捕获、记录和响应；重试需在业务方法用@retryable声明并保证幂等，补偿通过@recover实现，二者须解耦且前置设计。

全局异常处理本身不负责重试或补偿，它的职责是统一捕获、记录和响应异常；重试与补偿是业务执行层的容错策略，需在服务调用环节主动设计。二者应解耦协作：异常处理器只做“归因”和“上报”，而重试/补偿逻辑必须前置到具体方法中。

重试机制要放在业务方法上，不是异常处理器里

@ControllerAdvice 中的 GlobalExceptionHandler 是异常的“终点站”，它接收已发生的失败，无法再触发原操作重试——因为调用栈早已退出，上下文（如参数、事务状态、幂等标识）通常不可恢复。

• 重试必须在原始调用点声明，例如远程支付、库存扣减、消息发送等易受临时故障影响的操作
• 使用 @Retryable 注解配合 @EnableRetry，指定可重试异常（如 FeignException、SocketTimeoutException）、最大次数（3–5次）和指数退避（@Backoff(delay = 1000, multiplier = 2)）
• 确保被重试方法具备幂等性，避免重复扣款、重复发单等副作用

补偿逻辑通过 @Recover 绑定到重试链末端

当 @Retryable 尝试全部失败后，Spring Retry 会自动调用同类型签名的 @Recover 方法，这就是补偿入口。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• @Recover 方法需与 @Retryable 方法在同一类中，参数列表包含异常 + 原始入参（如 orderId、paymentId）
• 补偿动作应是确定性的修复操作，例如：调用反向接口释放冻结金额、更新订单状态为“支付失败”、写入死信队列待人工介入
• 补偿前务必基于业务 ID 查询最新状态，防止“已成功但未返回响应”的误补偿（即网络分区下的重复补偿）

异常处理器可辅助重试/补偿的可观测性

虽然不直接驱动重试，但 GlobalExceptionHandler 可以增强整个容错链路的可观测性：

• 对 不可重试异常（如 BusinessException、MethodArgumentNotValidException）打标并记录，便于识别哪些错误不该进重试流程
• 在响应头中添加 X-Retry-Status: exhausted 或 X-Compensation-Triggered: true，让客户端或网关感知当前请求已走完重试+补偿闭环
• 将重试耗尽事件推送到监控系统（如 Prometheus counter("retry.exhausted", "type", "payment")），用于告警和趋势分析

复杂场景建议用事件驱动+状态机编排

当重试与补偿涉及多个服务、需要跨事务或依赖外部确认时，不推荐纯注解方式。

• 将操作发布为领域事件（如 PaymentRequested），由独立消费者处理，并内置重试/补偿状态机
• 使用任务表（compensation_task）持久化待执行补偿项，搭配定时扫描 + 分布式锁，保障最终一致性
• 引入工作流引擎（如 Camunda、Temporal）显式建模“重试3次 → 补偿 → 人工审核”路径，支持断点续跑与人工干预