HttpClient.DefaultRequestHeaders仅对新建实例生效；单例复用才真正“全局”；User-Agent必须显式设置且格式合规；请求头分HttpRequestMessage.Headers（如Authorization）与Content.Headers（如Content-Type），混用将导致400或静默失败。
HttpClient.DefaultRequestHeaders 设置全局请求头
默认请求头只对后续新建的 HttpClient 实例生效，不是“全局覆盖所有请求”——这点常被误读。如果你用的是单例或静态 HttpClient（推荐做法），那设置一次就管用；但若每次 new 一个新实例，就得重复设。
常见错误：在 using var client = new HttpClient(); 里设 DefaultRequestHeaders，结果下一次 new 又得重设，还容易漏掉 User-Agent 导致被服务器拒绝。
-
User-Agent必须显式设置，否则某些 API（如 GitHub、Cloudflare 后端）会直接返回 403 - 不能用
Add("Key", "Value")重复添加同名头，会抛InvalidOperationException；改用TryAddWithoutValidation或先Remove再Add -
Accept、Content-Type这类头，建议在具体请求时用HttpRequestMessage设置，更灵活
HttpRequestMessage.Headers 和 .Content.Headers 区分场景
请求头分两类：一类属于 HTTP 报文头部（如 Authorization、User-Agent），走 HttpRequestMessage.Headers；另一类属于请求体的元数据（如 Content-Type、自定义 X-Request-ID），必须走 HttpRequestMessage.Content.Headers。混用会静默失败或触发 400。
典型场景：上传 JSON 时设 Content-Type: application/json，如果写到 .Headers 里，服务器根本收不到这个值。
-
HttpRequestMessage.Headers：放Authorization、User-Agent、Accept -
HttpRequestMessage.Content.Headers：放Content-Type、Content-MD5、X-Upload-Timestamp - POST 表单（
FormUrlEncodedContent）也要手动加Content-Type，它不会自动补
读取响应头：HttpResponseMessage.Headers vs .Content.Headers
响应头也分两层：HttpResponseMessage.Headers 是 HTTP 状态行之后的主响应头（如 Server、ETag、Retry-After），而 HttpResponseMessage.Content.Headers 是响应体相关的头（如 Content-Length、Content-Encoding）。漏看后者，可能错过压缩信息或实际字节数。
容易踩的坑：用 response.Headers.TryGetValues("Content-Type", out var vals) 查不到值——因为这个头其实在 response.Content.Headers 里。
- 检查
Content-Type、Content-Encoding一定去.Content.Headers -
Set-Cookie在.Headers中，但 .NET 默认不自动管理 Cookie，需自己解析并传给下次请求 - 自定义响应头（如
X-RateLimit-Remaining）通常在.Headers，但有些服务会故意塞到.Content.Headers里绕过中间件过滤
User-Agent 字符串写法和兼容性注意点
User-Agent 不是随便拼的字符串。很多服务（尤其是国内 CDN 或风控系统）会校验格式，空格、括号不匹配、含非法字符都可能导致 403 或限流。别用中文、emoji、长随机字符串。
标准写法应模仿主流浏览器或公认 SDK，比如 "MyApp/1.2.3 (Windows NT 10.0; Win64; x64) HttpClient/7.0"。括号内容非必须，但加上能提高通过率。
- 避免纯数字或纯字母组合，如
"123"、"test"，易被识别为爬虫 - 不要在
User-Agent里暴露敏感信息（如内网 IP、用户名） - 同一进程内频繁切换
User-Agent值，可能触发服务端行为分析，反而被限速
