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