应使用 DelegatingHandler 而非继承 HttpMessageHandler，因其安全、可维护且跨平台兼容；后者需手动实现连接池、TLS 等底层逻辑，易引发 SocketException、HTTPS 失败等问题。
别继承 HttpMessageHandler，直接用 DelegatingHandler——这是唯一安全、可维护、跨平台兼容的拦截方式。
为什么不能继承 HttpMessageHandler
你写的 public class MyHandler : HttpMessageHandler 看似合理，实则绕进了底层陷阱。.NET 6+ 已将 HttpClientHandler 标记为“不建议继承”，而 HttpMessageHandler 本身是抽象基类，不提供默认网络能力；它只定义契约，不管理连接池、DNS 缓存、TLS 握手、超时重试等——这些全得你自己实现。
常见后果包括：
-
SocketException频发，尤其高并发下连接耗尽 - HTTPS 请求失败（TLS 参数未正确传递）
- 请求无法取消（
cancellationToken没透传或被忽略） - .NET Core/.NET 5+ 中实际使用的是
SocketsHttpHandler，你绕过它就等于放弃所有现代优化
DelegatingHandler 的正确构造与注入
DelegatingHandler 是专为链式拦截设计的中间件式处理器，必须传入非空 innerHandler 才能工作。
错误写法（运行时报 ArgumentNullException: Value cannot be null. (Parameter 'innerHandler')）：
public class LoggingHandler : DelegatingHandler
{
public LoggingHandler() : base() { } // ❌ 无参构造，InnerHandler 为 null
}
正确写法（两种场景）：
- 手动构造：传入
new HttpClientHandler()或new SocketsHttpHandler() - 依赖注入（推荐）：注册时交由 DI 容器自动注入下游 handler
例如在 Program.cs 中：
services.AddHttpClient("api")
.AddHttpMessageHandler<AuthHandler>()
.AddHttpMessageHandler<LoggingHandler>();
DI 会按顺序构造链：AuthHandler → LoggingHandler → HttpClientHandler，并确保每个 InnerHandler 非空。
SendAsync 中修改请求和响应的注意事项
重写 SendAsync 是核心，但几个关键点极易出错：
-
request.RequestUri可直接赋值，但改完后某些认证方案（如 NTLM）可能失效 -
request.Headers.Host是只读属性，要用request.Headers.TryAddWithoutValidation("Host", "xxx") - 修改
request.Content前，若已调用ReadAsStringAsync()，必须Seek(0, SeekOrigin.Begin)，否则下游读到空流，返回400 Bad Request或超时 - 响应阶段处理
response.Content同理：若需读取响应体再返回，记得response.Content = new StringContent(...)替换，而非仅读取
示例（安全添加头 + 改写 URI）：
protected override async Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request,
CancellationToken cancellationToken)
{
request.Headers.TryAddWithoutValidation("X-Trace-ID", Guid.NewGuid().ToString());
var newUri = new Uri("https://gateway.example.com" + request.RequestUri.PathAndQuery);
request.RequestUri = newUri;
return await base.SendAsync(request, cancellationToken);
}
多个 DelegatingHandler 的执行顺序与调试盲区
handler 链是「请求正向进、响应逆向出」，但很多人误以为注册顺序 = 日志时间顺序。比如：
services.AddHttpClient("api")
.AddHttpMessageHandler<AuthHandler>()
.AddHttpMessageHandler<LoggingHandler>()
.AddHttpMessageHandler<RetryHandler>();
实际流程是：
- 请求：Auth → Logging → Retry → HttpClientHandler
- 响应：HttpClientHandler ← Retry ← Logging ← Auth
所以如果你在 LoggingHandler 里记录响应状态码，它看到的是 RetryHandler 处理后的结果（比如重试成功后的 200），而不是原始失败的 503。想定位真实失败原因，日志必须放在最靠近 HttpClientHandler 的位置，或者每个 handler 都记录「进入/离开」两个时间点。
另一个盲区：HttpClientFactory 默认管道里已有 LifetimeTrackingHttpMessageHandler、LoggingScopeHttpMessageHandler 等内置 handler，它们也会参与执行——调试时别只盯着自己写的 handler。
