C#中正确设置HTTP请求头需区分系统保留头与自定义头：Content-Type等须通过实体属性设置，Authorization等用Headers.Add()；DefaultRequestHeaders仅适用于全局不变头，动态头应使用HttpRequestMessage.Headers；Bearer认证推荐AuthenticationHeaderValue避免格式错误。
如何在 C# 中正确设置 HTTP 请求头
直接用 HttpClient 的 DefaultRequestHeaders 或单次请求的 Headers 添加即可，但必须避开「重复设置系统保留头」和「在请求已发送后修改」这两个最常踩的坑。
常见错误现象：InvalidOperationException: The 'xxx' header must be modified using the appropriate property（比如试图手动设 Content-Type、Host、Content-Length）。
- 系统自动管理的头（如
Content-Type、Content-Length、Host、Transfer-Encoding）不能用Add()，得通过对应实体属性设置：比如StringContent构造时传入mediaType，或用HttpRequestMessage.Content.Headers.ContentType - 自定义头（如
X-Api-Key、Authorization）才用client.DefaultRequestHeaders.Add("X-Api-Key", "abc123") - 若需每次请求不同值（如带用户 token），别用
DefaultRequestHeaders，改用HttpRequestMessage实例的Headers：
var req = new HttpRequestMessage(HttpMethod.Get, "https://api.example.com/data");
req.Headers.Add("Authorization", $"Bearer {userToken}");
req.Headers.Add("X-Request-ID", Guid.NewGuid().ToString());
var resp = await client.SendAsync(req);
为什么 HttpClient.DefaultRequestHeaders 不是万能的
它只影响「未显式覆盖该头的请求」，且一旦 HttpClient 实例被复用，这些默认头会持续存在——容易导致跨请求污染，尤其在多租户或 token 轮换场景下。
使用场景：适合真正全局不变的头，如固定 User-Agent、Accept；不适合带状态的认证头或请求级唯一标识。
-
DefaultRequestHeaders在首次调用SendAsync前设置才安全；之后修改可能不生效（取决于底层连接复用逻辑） - 并发请求中若多个线程共用同一
HttpClient并反复修改DefaultRequestHeaders，会出现竞态，结果不可预测 - 更稳妥的做法是封装一个工厂方法，每次生成新
HttpRequestMessage并注入所需头，把状态控制收口到请求构造阶段
Authorization 头的三种写法与兼容性差异
不是所有服务端都接受同一种格式，特别是老系统或自定义鉴权中间件，容易因大小写、空格、拼写出错而返回 401。
- 标准 Bearer：用
req.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token)（推荐，自动处理空格和编码） - 手动拼接：
req.Headers.Add("Authorization", $"Bearer {token}")—— 注意Bearer后必须有一个空格，且token本身不能含非法字符（需提前 URL 编码或 Base64 处理） - Basic 认证：用
Convert.ToBase64String(Encoding.UTF8.GetBytes($"{user}:{pass}"))构造凭据，再套"Basic xxx"，但注意避免明文密码硬编码
关键点：HTTP 头名不区分大小写，但值敏感；Authorization 的 scheme（如 Bearer）首字母大写是惯例，部分严格校验的网关会拒收小写 bearer。
底层原理：请求头何时真正写入网络流
头字段不是在调用 Add() 时就发出去的，而是在 SendAsync 执行、HttpMessageHandler 开始序列化 HttpRequestMessage 时，按 RFC 7230 规范拼成原始 HTTP 报文第一部分。这意味着：
- 直到那一刻，头才被校验合法性（例如是否含控制字符、换行符）；非法内容会抛
FormatException - 若用
WinHttpHandler（Windows 上默认），某些头（如Connection）会被重写或忽略，以适配 WinHTTP API 行为 - 抓包看不到你代码里加的头？先确认没被中间代理/防火墙过滤，再检查是否误设在
Content.Headers而非Headers（后者才是请求行以下的主头区）
真正难调试的，往往是头被静默覆盖或延迟校验——比如你设了 Accept: application/json，但又用了 JsonContent，后者会自动往 Content.Headers 写 application/json，和主头无关，但新手常混淆这两层。
