最可靠方式是同时读取 HttpResponseMessage.Headers 和 HttpResponseMessage.Content.Headers；前者存通用头（如 Server），后者存实体头（如 Content-Type），漏掉后者会丢失关键信息。
用 HttpClient 读取响应 Header 最可靠
直接用 HttpClient 发起请求后，Header 存在 HttpResponseMessage.Headers 和 HttpResponseMessage.Content.Headers 两个地方，漏掉后者会丢掉 Content-Type、Content-Length 这类关键信息。
常见错误是只查前者，结果发现 Content-Type 找不到——它其实在 Content.Headers 里。
-
Headers放通用头：如Server、Date、Cache-Control -
Content.Headers放实体头：如Content-Type、Content-Encoding、Content-Disposition - 必须等
HttpResponseMessage返回后再读，不能在异步未完成时访问
var client = new HttpClient();
var response = await client.GetAsync("https://httpbin.org/get");
// ✅ 正确读法
var server = response.Headers.Server?.ToString();
var contentType = response.Content.Headers.ContentType?.ToString();
遇到 InvalidOperationException: Headers are not supported 怎么办
这个错误通常出现在用 WebClient 或旧版 HttpWebRequest 时手动调用 GetResponse() 后又试图读取 Header，但底层连接已关闭或响应流已被消费。
根本原因是：这些老 API 对 Header 访问时机敏感，一旦调用了 GetResponseStream() 或读了 ResponseStream，Header 就可能失效。
- 优先换用
HttpClient，它是现代、线程安全、Header 可随时读的默认选择 - 如果必须用
HttpWebRequest，确保在调用GetResponse()后、且未触碰ResponseStream前就读完所有 Header -
WebClient几乎不暴露原始 Header，不推荐用于需要 Header 的场景
HttpClient 复用时 Header 会不会串？
不会。每个 HttpResponseMessage 实例的 Headers 和 Content.Headers 都是独立对象，和 HttpClient 实例无关。复用 HttpClient 不仅安全，而且必须这么做——否则容易触发端口耗尽。
- 一个
HttpClient实例可发成百上千个请求，每次响应的 Header 都隔离干净 - 别为每次请求 new 一个
HttpClient，这是最常见的性能坑 - 如果用了
IHttpClientFactory（如 ASP.NET Core），Header 行为完全一致，无需额外处理
中文 Header 值乱码怎么解
HTTP 协议本身不强制规定 Header 值编码，但 RFC 5987 允许用 filename*=UTF-8''xxx 形式编码，而 .NET 默认只按 ASCII 解析普通字段。遇到 Content-Disposition 里带中文文件名却显示问号，大概率是服务端用了 RFC 5987 编码但客户端没解码。
- .NET 6+ 已内置支持 RFC 5987 解码，直接读
ContentDisposition.FileNameStar属性即可 - 旧版本需手动解析
filename*字段，或改用第三方库如Microsoft.Net.Http.Headers - 不要尝试用
Encoding.UTF8.GetString()强转字节数组——Header 值不是原始字节流，而是已解析的字符串
Header 看似简单，但跨版本、跨实现、跨编码的细节太多，最容易栽在“以为读到了，其实读错了”上。
