应使用 IHttpClientFactory 管理 HttpClient 生命周期，避免端口耗尽等问题；推荐类型化客户端封装调用逻辑，通过 DI 注入预配置 HttpClient；handler 级配置（如连接池、HTTP/2）必须用 ConfigurePrimaryHttpMessageHandler。
别再每次请求都 new HttpClient() 了——这会导致端口耗尽、DNS 缓存不更新、SSL 会话无法复用，严重时直接报 SocketException: Only one usage of each socket address...。正确做法是交由 IHttpClientFactory 统一管理底层 HttpMessageHandler 生命周期，你只管“借”轻量级 HttpClient 实例用完即弃。
命名客户端：适合多服务、配置差异大的场景
用字符串名称区分不同后端（如 GitHub、支付网关、内部 API），注册时绑定基础配置，调用时按名取用。关键点是：配置只作用于新生成的 HttpClient 实例，不影响共享的 handler。
-
AddHttpClient("payment", c => { c.BaseAddress = new Uri("https://api.pay.example/"); c.Timeout = TimeSpan.FromSeconds(10); })—— 注册时设置默认地址和超时 - 注入
IHttpClientFactory后调用_factory.CreateClient("payment")，每次返回新实例，但底层 handler 很可能复用 - 避免魔法字符串：把名称定义为
const string PaymentClient = "payment";，统一管理 - 不推荐在循环里高频调用
CreateClient("xxx")—— 虽然安全，但无谓创建对象；应提取为字段或局部变量复用
类型化客户端：强类型、易测试、推荐首选
把 HTTP 调用封装成普通类，构造函数直接接收 HttpClient（不是 IHttpClientFactory），DI 容器自动供应带预设配置的实例。它不是单例，每次解析都新建，但内部 HttpClient 由工厂托管。
- 定义类：
public class WeatherService { private readonly HttpClient _client; public WeatherService(HttpClient client) { _client = client; _client.BaseAddress = new Uri("https://api.weather.com/"); } public async Task<string> GetForecastAsync(string city) => await _client.GetStringAsync($"v3/weather/forecast/daily/5day/{city}"); }</string> - 注册：
services.AddHttpClient<weatherservice>();</weatherservice>—— 自动关联默认 handler 和生命周期 - 使用：
public MyController(WeatherService weather) { ... }，完全解耦 HTTP 细节 - 注意：不要在类型化客户端里手动
Dispose_client，也不该缓存它；它的生命周期由 DI 控制
ConfigurePrimaryHttpMessageHandler：改底层 handler 的唯一正途
想调大连接池、启用 HTTP/2、控制 DNS 刷新或自定义 SSL 验证？这些都属于 HttpMessageHandler 级别配置，不能通过 AddHttpClient(...) 的 lambda 设置，必须走专用入口。
AddHttpClient("api").ConfigurePrimaryHttpMessageHandler(() => new SocketsHttpHandler { MaxConnectionsPerServer = 100, PooledConnectionLifetime = TimeSpan.FromMinutes(5), EnableMultipleHttp2Connections = true });- 错误写法：
c.MaxConnectionsPerServer = 100——c是HttpClient实例，这个属性根本不存在 - 若需全局 handler 配置（比如所有客户端都要走代理），用
services.Configure<httpclientfactoryoptions>(o => o.HttpClientActions.Add(...))</httpclientfactoryoptions>不起作用，必须用ConfigurePrimaryHttpMessageHandler - 自定义
SocketsHttpHandler时，记得设UseCookies = false（默认为true），否则可能意外共享CookieContainer，引发安全问题
常见误用与崩溃点
很多问题不是代码写错，而是对“谁拥有 handler”“谁负责释放”理解偏差。最危险的操作往往看起来最自然。
- 在类型化客户端里
new HttpClient(new HttpClientHandler())—— 彻底绕过工厂，重蹈端口耗尽覆辙 - 把
IHttpClientFactory.CreateClient()返回的实例存为静态字段或单例属性 —— 工厂设计本就不支持长期持有，且可能因 handler 回收导致后续请求失败 - 在
using var client = _factory.CreateClient();中包裹 ——HttpClient实例本身不需要Dispose，handler 由工厂管理；加using反而干扰 DI 生命周期跟踪 - WinForms 或控制台程序中漏装
Microsoft.Extensions.HttpNuGet 包 ——AddHttpClient扩展方法不可用，编译不过
真正容易被忽略的是 handler 配置的层级隔离：你改 HttpClient 的 Timeout，没问题；但想调 MaxConnectionsPerServer，就必须钻到 ConfigurePrimaryHttpMessageHandler 里去——这两层根本不在一个对象上，混用只会静默失效。
