IHttpClientFactory每次创建新HttpClient是否存在性能问题？

你看到的技术文章观点基本准确，但遗漏了关键的资源分层逻辑，常规使用IHttpClientFactory.CreateClient()不会产生性能问题。

首先明确Asp.Net Core 6中IHttpClientFactory的实现逻辑，拆分资源开销层级：

• 每次调用CreateClient()确实会返回一个全新的HttpClient实例，这部分没有池化。但HttpClient本身只是对下层消息处理器的薄包装，不持有socket连接、证书、连接池这类重非托管资源，构造过程仅做简单的对象初始化和handler绑定，单次构造耗时在亚微秒级，GC回收成本也极低，本身确实是轻量对象。
• 真正属于重资源的是HttpClient依赖的HttpMessageHandler链（核心为HttpClientHandler），这部分是由工厂统一池化管理的：默认handler生存期为2分钟，生存期内所有新建的HttpClient只要匹配配置规则，就会复用同一个handler实例，由handler维护的底层TCP连接池、DNS缓存、证书校验结果都会被复用，完全规避了早年直接new HttpClient()导致的socket耗尽、DNS无法更新的问题。

只有偏离官方设计的用法才会出问题，正常调用不会有性能风险：

• 绕开工厂的handler池化逻辑，在创建客户端时手动传入自定义的HttpClientHandler实例，会导致每次请求都新建重资源handler，退化成原生new HttpClient()的问题
• 将CreateClient()返回的HttpClient存为单例/静态变量长期持有，会导致绑定的handler过了生存期也无法被回收，DNS更新失效、连接池泄漏问题会复现
• 每秒数万次以上的超高频调用场景下，如果每次CreateClient()都附带大量重复的自定义配置（比如重复添加一堆请求头、自定义一堆handler包装），才可能产生可观测的性能损耗，99%的业务场景不会触及这个阈值。

• 常规业务场景直接调用CreateClient()即可，不需要缓存HttpClient实例，就算用using语句包裹客户端做释放也是安全的——工厂返回的客户端被Dispose时不会释放底层池化的handler，不会影响连接复用。
• 针对固定配置的下游服务，优先使用命名客户端或类型化客户端，在服务注册阶段提前完成客户端配置，避免每次调用时重复写配置逻辑，进一步降低开销：

// Program.cs 注册阶段预配置
builder.Services.AddHttpClient("PaymentService", client =>
{
    client.BaseAddress = new Uri("https://payment.internal.example.com");
    client.Timeout = TimeSpan.FromSeconds(5);
    client.DefaultRequestHeaders.Add("X-Service-Id", "OrderWebApi");
});

// 业务调用时直接拿预配置实例
var httpClient = _httpClientFactory.CreateClient("PaymentService");

• 需要加重试、熔断、超时等弹性策略时，在注册客户端阶段统一添加策略配置，不要在每次拿到客户端后重复包装策略，避免重复生成策略执行对象带来不必要的开销。
• 单服务QPS超过10万的极端高吞吐场景，可以在单个请求作用域内复用同一个HttpClient实例做微优化，这个优化的收益非常有限，非必要不需要做。

内容的提问来源于stack exchange，提问作者MiBuena