最稳方式是用 FormUrlEncodedContent，它自动处理 URL 编码、UTF-8 字符集、空值过滤；HttpClient 必须复用，推荐 IHttpClientFactory；注意字段名大小写敏感、Cookie 域匹配及后端隐式要求。
用 HttpClient 发送 application/x-www-form-urlencoded 数据最稳
直接用 HttpClient 配合 FormUrlEncodedContent，别手写字符串拼接或手动设 Content-Type。.NET Core 2.1+ 和 .NET 5+ 默认推荐这个路径，它自动处理 URL 编码、空值过滤、字符集（UTF-8）、换行符归一化。
-
FormUrlEncodedContent接收IEnumerable，键和值都会被> Uri.EscapeDataString编码，安全可靠 - 手动拼
"key=value&key2=value2"容易漏编码中文、空格、&、=，导致后端收不到或解析错 - 别自己调
client.DefaultRequestHeaders.Add("Content-Type", "...")——FormUrlEncodedContent已内置正确 header
var client = new HttpClient();
var data = new Dictionary<string string>
{
["username"] = "张三",
["token"] = "abc+123"
};
var content = new FormUrlEncodedContent(data);
var res = await client.PostAsync("https://api.example.com/login", content);</string>
遇到 400 或后端说“参数缺失”时先查 HttpRequestException 的 StatusCode 和响应体
很多“发送失败”其实是服务端拒绝，但 HttpClient 默认不抛异常（除非网络层失败），得主动检查 res.IsSuccessStatusCode。400 常见于字段名拼错、必填项为空、值超长、编码不一致（比如后端只认 UTF-8，你发了 GBK 字节）。
- 用
await res.Content.ReadAsStringAsync()看真实错误提示，比猜强得多 - 某些老接口要求
application/x-www-form-urlencoded;charset=GBK，但FormUrlEncodedContent固定用 UTF-8 —— 这时得退回到StringContent手动构造 - 字段名大小写敏感：后端要
userId，你传userid就算编码再对也没用
HttpClient 实例必须复用，别在每次请求里 new
频繁创建 HttpClient 会导致 socket 耗尽、DNS 缓存失效、TLS 握手重复，尤其在高并发或短生命周期场景（如 ASP.NET Core Controller Action）下极易出 SocketException 或连接超时。
- 全局单例或用
IHttpClientFactory（推荐，能自动管理生命周期、重试、日志） - 别写
using var client = new HttpClient();——Dispose()会关闭底层连接池 - 如果必须设超时或自定义 header，用
HttpClientFactory的命名客户端，而不是每次 new
需要带 Cookie 或模拟浏览器行为？加 CookieContainer 要小心域和路径匹配
原生 HttpClient 不维护 Cookie，要用 HttpClientHandler + CookieContainer。但默认行为和浏览器不同：它不会自动处理 Set-Cookie 的 Domain 和 Path 规则，比如后端设 Domain=.example.com，你请求 api.example.com 时可能不带上。
- 初始化
HttpClientHandler时传入新CookieContainer，别复用多个 handler 共享一个容器 - 确保请求 URL 的 host 和
Set-Cookie的Domain匹配（注意前导点），否则 cookie 被静默丢弃 - 调试时可用
container.GetCookies(new Uri(url))检查是否真存进去了
实际用下来，最难缠的不是怎么发，而是后端文档写得模糊——比如声称“支持表单提交”，结果暗地里校验 User-Agent、要求特定 Referer、或者把空字符串当 null 处理。这些没法靠客户端库解决，得抓包比对浏览器行为。
