直接用 DelegatingHandler 就行，别绕到 HttpMessageHandler 基类去重写底层逻辑——那不是“进阶”，是自找麻烦。
为什么不该继承 HttpMessageHandler？
你看到的大多数“拦截教程”里写的 public class MyHandler : HttpMessageHandler，本质上是在重复造轮子。.NET 的 HttpClient 管道设计明确把拦截职责交给 DelegatingHandler，它专为链式处理而生；而 HttpMessageHandler 是底层传输实现（比如 HttpClientHandler 或 SocketsHttpHandler），直接继承它意味着你要自己管理连接池、DNS、TLS、超时、重试……这些全都不该由业务拦截器碰。
- 继承
HttpMessageHandler后无法复用默认的连接复用机制，容易引发SocketException或连接耗尽 - 在 .NET 6+ 中，
HttpClientHandler已被标记为“不建议继承”，官方文档明确推荐用DelegatingHandler - 你写的
SendAsync若没正确传递cancellationToken，会导致请求无法取消，UI 冻结或后台任务卡死
DelegatingHandler 的正确构造方式
必须传入 innerHandler，且不能为 null ——否则运行时报 ArgumentNullException: Value cannot be null. (Parameter 'innerHandler')。这不是可选步骤，是管道链存在的前提。
- 错误写法：
new LoggingHandler()（无参构造）→ 编译可能过，但运行必崩 - 正确写法：
new LoggingHandler(new HttpClientHandler())，或更推荐：new LoggingHandler(outerHandler)，其中outerHandler是上一级 handler 或最终的HttpClientHandler - 若用
HttpClientFactory，应这样注册：services.AddHttpClient("api").AddHttpMessageHandler，DI 容器会自动注入正确的(); innerHandler
多个 DelegatingHandler 的执行顺序陷阱
handler 链是“请求正向进入、响应逆向返回”，但很多人误以为添加顺序 = 执行顺序，结果日志打乱、Token 覆盖失败、缓存逻辑错位。
- 假设你调用：
HttpClient client = HttpClientFactory.Create(new AuthHandler(), new LoggingHandler(), new RetryHandler()); - 请求阶段：AuthHandler → LoggingHandler → RetryHandler →
HttpClientHandler - 响应阶段：
HttpClientHandler← RetryHandler ← LoggingHandler ← AuthHandler - 所以：想让日志记录最终响应状态，
LoggingHandler必须放在链**靠后位置**；想让 Token 注入早于所有其他修改，AuthHandler必须放**最前**
响应体读取与重放的常见崩溃点
想在 SendAsync 里读取 response.Content.ReadAsStringAsync()？小心 ObjectDisposedException 或空内容——因为 HttpResponseMessage 的 content stream 默认只能读一次，且可能已被下游 handler 提前消费。
- 必须先调用
response.Content.LoadIntoBufferAsync()，再读取，否则后续业务代码拿不到 body - 若要修改响应内容（如注入调试头），得用
new StringContent(modifiedJson, Encoding.UTF8, "application/json")替换原response.Content - 别在 handler 里直接 await
response.Content.ReadAsByteArrayAsync()后又返回原response——stream 已关闭，下游会抛ObjectDisposedException
真正难的从来不是写一个 handler，而是理解它嵌在哪条链里、谁先谁后、谁动了 stream、谁吞了 cancellation。漏掉任意一点，线上就出 HttpRequestException 或内存泄漏。
