DelegatingHandler 是唯一可安全拦截并修改 HTTP 请求/响应的处理器，HttpClientHandler 不支持重写 SendAsync；需继承 DelegatingHandler，通过 TryAddWithoutValidation 修改头、重写 RequestUri，并谨慎处理 Content Stream 复用与响应体替换。
HttpClientHandler 不能直接拦截请求体，得用 DelegatingHandler
想在发送前修改 HttpRequestMessage（比如加 header、改 URL、重写 body），HttpClientHandler 本身不提供拦截入口——它只负责底层网络通信。真正能插手请求/响应流程的是 DelegatingHandler，它是可链式嵌套的中间件式处理器。
常见错误是试图重写 HttpClientHandler.SendAsync，结果编译失败或被忽略，因为该方法是 protected 且不可重写（它不是虚方法）。
- 必须继承
DelegatingHandler，重写SendAsync - 构造时传入下游 handler（通常是
new HttpClientHandler()），否则会无限递归 - 修改请求后，必须调用
base.SendAsync(request, cancellationToken)向下游转发
如何在 SendAsync 中安全修改请求头和 URL
修改 request.RequestUri 或 request.Headers 是安全的，但要注意：URI 修改后，某些认证逻辑（如 NTLM）可能失效；Header 修改需避开只读集合（如 request.Headers.Host 是只读的，应改用 request.Headers.TryAddWithoutValidation）。
public class LoggingHandler : DelegatingHandler
{
public LoggingHandler(HttpMessageHandler innerHandler) : base(innerHandler) { }
protected override async Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request, CancellationToken cancellationToken)
{
// 修改 Host 头（绕过只读限制）
request.Headers.TryAddWithoutValidation("Host", "api.example.com");
// 添加自定义头
request.Headers.Add("X-Request-ID", Guid.NewGuid().ToString());
// 重写 URI（例如统一加前缀）
var uri = new Uri("https://proxy.example.com" + request.RequestUri.PathAndQuery);
request.RequestUri = uri;
return await base.SendAsync(request, cancellationToken);
}
}
修改请求体（body）要小心 Stream 复用问题
HttpRequestMessage.Content 的 Stream 默认只能读一次。直接 ReadAsStringAsync() 后不重置位置，会导致下游 handler 读到空内容，返回 400 或超时。
- 若只需查看 body，用
await request.Content.ReadAsByteArrayAsync()+new ByteArrayContent(...)重建 Content - 若要文本替换，先读取为 string，修改后再转回
StringContent（注意编码和ContentType） - 避免直接操作原始
Stream，除非你手动Seek(0, SeekOrigin.Begin)并确保下游不依赖原始流状态
示例：注入 JSON 字段
var json = await request.Content.ReadAsStringAsync(); var obj = JsonSerializer.Deserialize<JsonElement>(json); using var doc = JsonDocument.Parse(json); var root = doc.RootElement.Clone(); // 插入新字段 // ... 省略修改逻辑 var newJson = JsonSerializer.Serialize(root); request.Content = new StringContent(newJson, Encoding.UTF8, "application/json");
响应拦截同样走 SendAsync，但要注意异步资源释放
响应拦截写在 await base.SendAsync(...) 之后。常见需求是记录耗时、解密响应体、重试逻辑。但别忘了：如果修改了 response.Content，必须确保新 Content 的 Headers.ContentType 正确，且旧 Content 已被释放（尤其用了 HttpContentExtensions.ReadAsByteArrayAsync 后）。
容易被忽略的点：
- 未
await response.Content.LoadIntoBufferAsync()就直接ReadAsStringAsync()，可能触发多次读取异常 - 用
new StringContent(...)替换响应体后，没设置response.Content.Headers.ContentType，导致前端解析失败 - 在异常路径中（如 try/catch）没正确处理
response?.Dispose()，引发连接泄漏
实际项目里，body 修改和响应重写是最容易出兼容性问题的地方，尤其是对接老系统或非标准 API 时，建议先做最小化验证，再逐步叠加逻辑。
