不带指数退避的重试会引发雪崩；C#中用HttpClient上传文件时，若仅用简单while循环重试且未加退避，失败响应（如4xx/5xx）将导致请求洪峰压垮后端。
重试逻辑没加退避，HttpClient 会瞬间打爆后端
直接上结论：不带指数退避（exponential backoff）的重试，等于主动制造雪崩。C# 里用 HttpClient 或 IHttpClientFactory 做文件上传时，如果只写个简单 while (retryCount ，失败瞬间重试三次，所有并发请求都会在几毫秒内叠加重试流量。
常见错误现象：HttpRequestException 暴增、后端 CPU 突升、网关返回 429 Too Many Requests 或直接超时断连。
- 必须用
PolicyWrap组合WaitAndRetryAsync+CircuitBreakerAsync，不能只靠重试 -
WaitAndRetryAsync的间隔不能是固定值，比如TimeSpan.FromMilliseconds(100)—— 要用Backoff.DecorrelatedJitterBackoffV2这类策略生成随机抖动间隔 - 上传大文件时，
HttpRequestException可能来自连接中断或读取超时，这类错误必须和5xx一样纳入重试范围，但4xx（如400 Bad Request）绝对不能重试
IHttpClientFactory 配置里漏掉 AddPolicyHandler，重试根本不会生效
很多人以为只要在业务代码里包一层 Policy.WrapAsync(...).ExecuteAsync(...) 就行了，其实这样绕过了 IHttpClientFactory 的生命周期管理，导致连接复用失效、DNS 缓存丢失、甚至 SocketException: Too many open files。
正确做法是把策略注册进工厂，让每次 GetClient() 返回的实例自带重试能力：
services.AddHttpClient<IFileUploader, FileUploader>()
.AddPolicyHandler(GetRetryPolicy())
.AddPolicyHandler(GetCircuitBreakerPolicy());其中 GetRetryPolicy() 必须返回 AsyncRetryPolicy<HttpResponseMessage>，且内部要处理 HttpRequestException 和状态码；GetCircuitBreakerPolicy() 则需配置失败率阈值（比如连续 5 次失败触发熔断），避免重试风暴扩散到整个服务。
上传文件时没设 Timeout，重试反而延长故障时间
默认 HttpClient.Timeout 是 100 秒，而文件上传可能卡在中间某次重试的长等待里，用户等不到响应，监控也看不出异常——因为请求还在“活着”，只是没进展。
- 必须显式设置
Timeout，建议按文件大小分级：小文件（10MB）改用分块上传 + 单块超时控制 - 不要依赖
CancellationToken外部取消来替代超时，因为重试策略内部需要感知超时并分类为可重试错误 - 若用
MultipartFormDataContent构造上传体，注意StreamContent的底层流未设置ReadTimeout会导致阻塞不抛异常——得用FileStream并开启leaveOpen: true，再配合HttpClient.Timeout
没区分上传失败类型，把 401 Unauthorized 当成网络问题重试
这是最隐蔽的坑：token 过期、签名错误、权限不足，都返回 4xx，但日志里只看到“上传失败，正在重试第 1 次”，没人意识到是认证链路出问题。
真实场景中，这类错误重试只会快速耗尽 token 刷新配额，或触发风控限流。
- 重试策略里必须用
HandleResult显式排除4xx：例如.HandleResult(r => r.StatusCode >= HttpStatusCode.BadRequest && r.StatusCode - 对
401和403，应该走单独的 token 刷新流程，而不是重试上传本身 - 如果后端返回自定义错误码（如
{ "code": "INVALID_SIGNATURE" }），要在HttpResponseMessage.Content.ReadAsAsync<object>()后解析 body 再判断，不能只看状态码
重试不是万能胶，它只对临时性故障有效。上传失败真正难的，是第一时间分清是网络抖动、服务过载，还是你自己的参数写错了——后者重试一百次也没用。
