第三方请求偶尔失败时，直接增加重试次数很容易放大负载。对于创建、扣费或发送类操作，响应丢失还会让调用方无法确定业务是否已完成。调用策略必须同时考虑等待预算和重复效果。
给每类操作定义失败语义
查询与写入不能统一处理。请求未发出、已发出但超时、对方明确拒绝，是不同状态。写入结果未知时，优先使用业务查询或对账确认，不能把超时直接解释为对方没有执行。
重试需要条件和总预算
限定可重试错误、尝试次数、间隔以及整条业务允许等待的时间。多层各自重试会叠加，应明确由哪一层负责。对于已有流量压力的依赖，持续快速重试可能使恢复更困难。
管理连接与处理器生命周期
可使用 IHttpClientFactory 等方式管理客户端配置与处理器复用，但仍需理解 DNS 更新、凭证、Cookie 和处理器状态的影响。不要把每次 new HttpClient 或永远共享一个任意配置的实例当成通用答案。
验收“成功但响应丢失”
让测试服务先记录业务成功，再模拟调用方收不到结果。检查系统是否避免重复执行、是否能查询最终状态，并留有可追踪的请求标识。只测试连接失败无法覆盖这类风险。
常见问题：所有 5xx 都应该重试吗？
不能一概而论。需要结合操作副作用、对方契约和总等待预算判断，并为结果未知提供查询或人工处理路径。
技术参考：微软：IHttpClientFactory。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果内部团队需要把这些约定落到可运行的工程中，可以通过微服务基础架构建设沟通接口、公共能力与交接范围，先以一个业务场景验证方案。