C#怎么发送POST请求参数_C#使用FormUrlEncodedContent传值【网络】

C#发送POST请求：为什么FormUrlEncodedContent是你的首选

直接用 HttpClient 配合 FormUrlEncodedContent 发送 POST 表单数据是最稳妥、最常用的方式，别碰 WebClient 或手动拼接 string 再转 byte[] —— 容易乱码、漏编码、不兼容空格和特殊字符。

为什么必须用 FormUrlEncodedContent 而不是自己拼字符串

手动拼接 "key1=value1&key2=value2" 看似简单直接，但背后其实藏着三个“坑”，稍不留神就会掉进去：

• 当 value 里包含空格、中文、&、= 这类特殊字符时，如果不手动调用 Uri.EscapeDataString() 进行编码，服务端要么收不到完整数据，要么解析出错。
• 不同的 .NET 版本对默认编码的处理可能不一致。比如 .NET Framework 默认用 UTF-8，但一些遗留的老服务可能期望的是 GB2312，手动处理很容易出现乱码。
• 忘记设置 Content-Type: application/x-www-form-urlencoded 请求头。部分后端框架（例如 Spring Boot）对请求头有严格校验，缺少这个头会直接拒绝请求。

而 FormUrlEncodedContent 这个类，就是专门为解决这些问题而生的。它会自动完成 URL 编码，并正确设置好请求头，既省心又完全符合 HTTP 规范。

HttpClient 实例要不要每次 new？

这是一个关键的性能和资源管理问题。答案是：必须复用 HttpClient 实例。切忌在方法内部使用 new HttpClient() 这种写法。

为什么？因为每次新建和释放 HttpClient 都会带来不小的开销：可能导致底层 Socket 端口耗尽、DNS 缓存失效，更重要的是无法复用 HTTP 连接，严重影响性能。

• 最简单安全的做法是全局声明一个 static readonly HttpClient 实例。不过要注意，不要随意修改它的 DefaultRequestHeaders，以免影响其他请求。
• 如果需要为不同请求配置不同的参数（比如携带不同的 Token、设置不同的超时时间），推荐使用 HttpClientFactory（.NET Core 2.1+ 提供），或者将客户端封装成独立的类来管理。
• 记住，HttpClient 不是用完就丢的“短命”对象，所以不要调用它的 Dispose() 方法，也不要用 using 语句块包裹它。

来看一个标准的示例：

private static readonly HttpClient client = new HttpClient();
// 后续所有请求都用这个 client

传参时怎么处理 null、空字符串、嵌套对象

FormUrlEncodedContent 的构造函数只接受 IDictionary 类型的参数，所以在准备数据时需要注意以下几点：

• null 值：必须提前过滤掉。如果字典中某个键值对的 Value 为 null，构造 FormUrlEncodedContent 时会直接抛出 ArgumentNullException。
• 空字符串：这是合法的，它会被编码成类似 key= 的形式，服务端通常能够正常接收和处理。
• 嵌套对象：无法自动展开。例如一个 User.Address.City 这样的属性，需要手动“展平”成一级的键值对：dict["User.Address.City"] = "Beijing"。
• 数组或集合：需要按照表单提交的习惯，使用多个同名的 key。幸运的是，FormUrlEncodedContent 支持重复的 key，所以你可以这样写：dict.Add("ids", "1"); dict.Add("ids", "2")。

下面是一个常见的代码写法，涵盖了上述几种情况：

var data = new Dictionary
{
    ["username"] = "admin",
    ["password"] = "p@ss w0rd", // 空格和符号会被自动编码
    ["tag"] = ""
};
var content = new FormUrlEncodedContent(data);
var response = await client.PostAsync("https://api.example.com/login", content);

遇到 400 或参数全为空，先查这三件事

如果请求返回了 400 Bad Request，或者服务端反馈收到的参数全是空的，先别急着怀疑自己的业务逻辑。这类问题，八成是协议层面的细节没有对齐。可以从以下三个方面排查：

• 抓包确认请求格式：用工具（如 Fiddler、Wireshark）抓包，检查发出的请求头是否真的包含 Content-Type: application/x-www-form-urlencoded，并且请求体是 username=admin&password=xxx 这种格式，而不是 JSON。
• 核对接口文档：再次确认服务端接口文档是否真的要求表单提交。有些所谓的“POST 接口”实际上要求的是 application/json 格式，这时候就应该使用 JsonContent 而不是 FormUrlEncodedContent。
• 检查其他请求头：服务端可能还会校验 Referer、Origin 或要求特定的 User-Agent。这些虽然不影响参数传递，但同样会导致请求被拒绝（返回 400 或 403）。

还有一个容易被忽略的细节：某些内网服务或老旧系统会强制要求请求头中包含 Accept: */*。而 HttpClient 默认不会发送这个头。解决办法很简单，加上下面这行代码即可：

client.DefaultRequestHeaders.Accept.Clear();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("*/*"));