C# Polly重试与回退策略使用详解

Retry策略需显式指定异常或结果处理条件，推荐指数退避；Fallback提供兜底行为，须与Retry类型一致并组合使用；异步场景下必须全程传递CancellationToken。

Retry 策略：什么时候重试、重试几次、间隔怎么设

Retry 不是盲目重试，它只对特定异常或返回值生效。默认情况下 Polly 的 Retry 不捕获任何异常，必须显式指定 Handle 或用谓词判断。

常见错误是直接写 WaitAndRetry(3) 却没指定捕获哪些异常，结果异常直接抛出，重试根本没触发。

• 用 Handle() 捕获 HTTP 请求失败
• 用 HandleResult(r => r == null || r.IsSuccess == false) 处理返回值语义失败（比如 API 返回 200 但 body 中 success: false）
• 推荐用指数退避：WaitAndRetryAsync(3, retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)))，避免雪崩
• 注意：同步 Retry（如 Execute）会阻塞线程；I/O 场景务必用 RetryAsync + ExecuteAsync

var retryPolicy = Policy
    .Handle()
    .OrResult(r => !r.IsSuccessStatusCode)
    .WaitAndRetryAsync(
        retryCount: 3,
        sleepDurationProvider: retryAttempt => TimeSpan.FromMilliseconds(100 * Math.Pow(2, retryAttempt)),
        onRetry: (outcome, timespan, retryCount, context) =>
        {
            Console.WriteLine($"Retry {retryCount} after {timespan.TotalMilliseconds}ms");
        });

Fallback 策略：当重试也失败时，提供兜底行为

Fallback 不是“重试失败后自动执行”，而是独立策略，常与 Retry 组合使用（通过 WrapAsync）。它的核心是定义“失败时返回什么”或“执行什么补偿逻辑”。

容易踩的坑：把 Fallback 当作日志记录或监控钩子单独用——它必须有明确的返回值（或 Task），否则编译不通过；且一旦触发，原始异常/结果就丢弃了。

• 返回默认值：FallbackAsync("default")，适用于 string 类型操作
• 执行异步补偿逻辑：FallbackAsync(async ct => { await LogFailureAsync(); return default(T); })
• 访问原始异常：用 onFallbackAsync 回调，参数是 DelegateResult，其中 Outcome.Exception 或 Outcome.Result 可取到上下文
• 注意：Fallback 的泛型类型必须和被包装的策略一致，否则 WrapAsync 编译失败

var fallbackPolicy = Policy
    .Handle()
    .OrResult(r => r == null)
    .FallbackAsync(
        fallbackValue: "fallback-content",
        onFallbackAsync: (outcome, context) =>
        {
            var ex = outcome.Exception?.InnerException ?? outcome.Exception;
            Console.WriteLine($"Fallback triggered: {ex?.Message}");
            return Task.CompletedTask;
        });

Retry + Fallback 组合：顺序和异常传递很关键

用 Policy.WrapAsync(retryPolicy, fallbackPolicy) 时，执行流是：先走 Retry，所有重试耗尽后仍失败 → 触发 Fallback。但 Fallback 并不会“看到” Retry 过程中的每一次失败，只看到最终失败结果。

真正容易忽略的是上下文传递和异常屏蔽：如果 Retry 内部已处理并吞掉异常（比如用 ExecuteAndCaptureAsync），Fallback 就收不到异常；反之，Fallback 若抛出新异常，上层就收不到原始异常信息。

• 组合前确认两个策略的泛型类型严格一致（比如都是 Policy）
• 调试时在 onRetry 和 onFallbackAsync 中打印日志，验证是否按预期触发
• 不要在 Fallback 里再调用可能失败的外部服务——这会让兜底逻辑本身不可靠
• 若需区分“重试全部失败”和“首次就失败”，可在 context 中传入标记，或在 onFallbackAsync 中检查 outcome.FinalException

异步策略下 cancellation token 的传递不能漏

所有 *Async 方法都接受 CancellationToken，但很多人只传给最外层 ExecuteAsync，忘了策略内部也需要它。比如网络请求超时后，Retry 的等待延时仍会继续执行，造成“取消不彻底”。

WaitAndRetryAsync 的 sleepDurationProvider 函数本身不接收 CancellationToken，但你可以在回调里主动检查；更稳妥的做法是用 WaitAndRetryAsync(..., onRetryAsync: ...) 的异步版本，在其中 ct.ThrowIfCancellationRequested()。

• 始终把 cancellationToken 传给 ExecuteAsync(..., cancellationToken)
• 在 onRetryAsync 回调开头加 ct.ThrowIfCancellationRequested()
• Fallback 的 fallbackAction 如果是异步委托，也必须声明 CancellationToken 参数并参与协作取消

组合策略的健壮性不取决于重试次数多寡，而在于每次失败是否被准确识别、每次等待是否可中断、每次兜底是否真正可控——这些细节在压测或网络抖动时才会暴露。