Retry策略需显式指定异常或结果处理条件，推荐指数退避；Fallback提供兜底行为，须与Retry类型一致并组合使用；异步场景下必须全程传递CancellationToken。
Retry 策略：什么时候重试、重试几次、间隔怎么设
Retry 不是盲目重试，它只对特定异常或返回值生效。默认情况下 Polly 的 Retry 不捕获任何异常，必须显式指定 Handle 或用谓词判断。
常见错误是直接写 WaitAndRetry(3) 却没指定捕获哪些异常，结果异常直接抛出，重试根本没触发。
- 用
Handle捕获 HTTP 请求失败() - 用
HandleResult处理返回值语义失败（比如 API 返回 200 但 body 中(r => r == null || r.IsSuccess == false) 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参数并参与协作取消
组合策略的健壮性不取决于重试次数多寡，而在于每次失败是否被准确识别、每次等待是否可中断、每次兜底是否真正可控——这些细节在压测或网络抖动时才会暴露。
