Retry 策略：什么时候重试、重试几次、间隔怎么设
Retry 不是盲目重试，它只对特定异常或返回值生效。默认情况下
Polly的
Retry不捕获任何异常，必须显式指定
Handle<exceptiontype></exceptiontype>或用谓词判断。
常见错误是直接写
WaitAndRetry(3)却没指定捕获哪些异常，结果异常直接抛出，重试根本没触发。 用
Handle<httprequestexception>()</httprequestexception>捕获 HTTP 请求失败 用
HandleResult<t>(r => r == null || r.IsSuccess == false)</t>处理返回值语义失败（比如 API 返回 200 但 body 中
success: false） 推荐用指数退避：
WaitAndRetryAsync(3, retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)))，避免雪崩 注意：同步
Retry（如
Execute）会阻塞线程；I/O 场景务必用
RetryAsync+
ExecuteAsync
var retryPolicy = Policy
.Handle<HttpRequestException>()
.OrResult<HttpResponseMessage>(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<t></t>，其中
Outcome.Exception或
Outcome.Result可取到上下文 注意：Fallback 的泛型类型必须和被包装的策略一致，否则
WrapAsync编译失败
var fallbackPolicy = Policy<string>
.Handle<HttpRequestException>()
.OrResult<string>(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<httpresponsemessage></httpresponsemessage>） 调试时在
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参数并参与协作取消
组合策略的健壮性不取决于重试次数多寡，而在于每次失败是否被准确识别、每次等待是否可中断、每次兜底是否真正可控——这些细节在压测或网络抖动时才会暴露。
