XML上传失败不能只靠简单for循环重试，因需应对503/429/超时等场景，必须结合退避策略、熔断保护（如Resilience4j或Polly）与上下文隔离；重试时须确保XML内容可重放、字节一致，并配合幂等键。

XML上传失败时为什么不能只靠简单for循环重试

因为网络抖动、服务端限流或临时认证失效导致的 HTTP 503、429 或连接超时，往往需要带退避策略、熔断保护和上下文隔离的重试——裸写 for (int i = 0; i 容易掩盖真实错误、阻塞线程、甚至引发雪崩。

• 无指数退避：连续重试会加剧后端压力，可能让本可恢复的服务彻底不可用
• 无异常过滤：把 400 Bad Request（客户端数据错误）也重试，毫无意义
• 无超时控制：单次请求卡死，整个重试流程挂住
• 无监控钩子：失败多少次、耗时分布、是否触发熔断，全不可见

用 Polly 配置 XML 上传的弹性策略（.NET）

Polly 是 .NET 生态最成熟的弹性库，适合封装 HttpClient 发起的 XML POST 请求。关键是要组合 Retry、CircuitBreaker 和 Timeout 策略，并只对可重试状态码生效。

• 只重试 500、502、503、504 和连接异常，跳过 4xx（除 429）
• 使用 ExponentialBackoff：第1次等 1s，第2次约 2s，第3次约 4s
• 熔断器设为“连续 5 次失败后开启，持续 30 秒”，避免故障扩散
• 每个重试分支都带 HttpContext 或唯一 requestId，方便日志追踪原始 XML 内容

var retryPolicy = Policy
  .Handle()
  .OrResult(r => r?.StatusCode is StatusCode.ServiceUnavailable or StatusCode.BadGateway or StatusCode.GatewayTimeout or StatusCode.RequestTimeout)
  .WaitAndRetryAsync(
    retryCount: 3,
    sleepDurationProvider: attempt => TimeSpan.FromSeconds(Math.Pow(2, attempt - 1)),
    onRetry: (outcome, timespan, retryCount, context) =>
    {
      Log.Warning("XML upload failed (attempt {RetryCount}), retrying in {SleepMs}ms", retryCount, timespan.TotalMilliseconds);
    });
var circuitBreaker = Policy
.Handle()
.CircuitBreakerAsync(
exceptionsAllowedBeforeBreaking: 5,
durationOfBreak: TimeSpan.FromSeconds(30));

Resilience4j 替代方案（Java/Spring Boot）

如果你用的是 Spring Boot + RestTemplate 或 WebClient，Resilience4j 更轻量、无反射依赖，且天然支持 RetryConfig 的细粒度配置。

• 必须显式调用 Retry.decorateSupplier() 包裹实际上传逻辑，否则策略不生效
• ignoreExceptions 列表里要加上 IllegalArgumentException——防止 XML 序列化失败被误重试
• 通过 RetryRegistry 全局注册策略，便于统一调整所有 XML 接口的重试参数
• 注意 WebClient 是响应式，需用 Retry.decorateMono() 而非 decorateSupplier()

RetryConfig config = RetryConfig.custom()
  .maxAttempts(3)
  .waitDuration(Duration.ofSeconds(1))
  .intervalFunction(IntervalFunction.ofExponentialBackoff())
  .retryExceptions(IOException.class, TimeoutException.class)
  .ignoreExceptions(IllegalArgumentException.class)
  .failAfterMaxAttempts(true)
  .build();
Retry retry = Retry.of("xml-upload", config);
Supplier> supplier = () -> restTemplate.postForEntity(url, xmlEntity, String.class);
ResponseEntity result = retry.executeSupplier(supplier);

重试时 XML 内容怎么保证不丢失或重复提交

这是最容易被忽略的底层细节：HTTP 客户端重试时，如果请求体是流式（如 FileInputStream 或未缓存的 ByteArrayOutputStream），第二次重试会读到空内容——直接导致 400 或空 XML 被接收。

• .NET 中用 new StringContent(xmlString, Encoding.UTF8, "application/xml")，而非直接传 Stream
• Java 中用 new ByteArrayResource(xmlBytes) 或 new StringEntity(xmlString, ContentType.APPLICATION_XML)
• 若 XML 来自大文件，必须先完整读入内存或生成可重放的 InputStream（如 new ByteArrayInputStream(Files.readAllBytes(path))）
• 在重试日志中打印 xmlHash.substring(0, 8) 而非全文，既可去重又不泄露敏感字段

真正的难点不在加库，而在确认每次重试发出的 XML 字节完全一致，并且服务端有幂等键（如 Idempotency-Key header）配合校验。

https://www.php.cn/faq/2034740.html