最稳妥的POST参数拼接方式是使用http_build_query，它自动urlencode键值并符合RFC 3986规范；手动拼接或urldecode易致中文、空格等编码错误；仅适用于application/x-www-form-urlencoded场景，上传文件需用curlFile或手动构造multipart body。
php 中用 http_build_query 拼接 POST 参数最稳妥
直接用 urldecode 或手动拼 a=1&b=2 容易出编码错误，尤其是含中文、空格、特殊符号时。PHP 原生的 http_build_query 是专为此设计的，它会自动对键和值做 urlencode，并按 RFC 3986 规范处理保留字符。
常见错误现象：curl_setopt($ch, CURLOPT_POSTFIELDS, 'name=张三&city=北京') 发过去后服务端收不到 city，或值变成乱码 —— 这是因为没编码，空格变 +、中文被截断。
- 必须用
http_build_query，别手拼 - 传入数组，不要传字符串
- 默认编码为
UTF-8，若接口要求GBK，需先用iconv('UTF-8', 'GBK//IGNORE', $val)转换值再进数组 - 如果参数里有
NULL或空数组，http_build_query会跳过，不是报错 —— 注意检查数据完整性
什么时候不能用 http_build_query？
当目标接口明确要求「不编码」或「自定义编码规则」（极少见），或者你正在构造 multipart/form-data 请求体（比如上传文件）—— 此时不能直接用 http_build_query，它只适用于 application/x-www-form-urlencoded 场景。
典型误用：curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($data)) 用于上传文件 → 服务端收不到文件字段，因为没 boundary，也没分隔符。
立即学习“PHP免费学习笔记（深入）”；
- 纯表单字段（无文件）→ 用
http_build_query - 含文件 → 改用
CURLFile或手动构造 multipart body - 接口文档写明「参数需 base64 编码后再拼接」→ 先
base64_encode值，再进数组交给http_build_query
urlencode 和 rawurlencode 的区别会影响拼接结果
两者都编码字符串，但空格处理不同：urlencode 把空格转成 +，rawurlencode 转成 %20。而 http_build_query 内部用的是 urlencode，所以最终生成的字符串里会出现 +。
如果服务端严格校验签名（比如把 + 当普通字符参与 Hmac 计算），而你本地用 rawurlencode 拼的串去签名，就会验签失败。
- 绝大多数 HTTP 表单接口接受
+，无需干预 - 若验签失败，先确认服务端用的是哪种解码方式（
urldecode还是rawurldecode） - 必要时可自己模拟
http_build_query行为：遍历数组，对每个key和value用urlencode，再用&拼接
cURL 发送前记得设对 Content-Type
只拼对参数还不够。如果没显式设置 header，cURL 默认不发 Content-Type，某些接口（尤其 java spring Boot）会直接 400 拒绝请求。
错误写法：curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($data)) → 缺 header
- 必须加：
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/x-www-form-urlencoded']) - 不要写成
application/json或漏掉-（如写成xwwwformurlencoded） - 如果接口同时支持 GET 查询参数 + POST body，注意 GET 部分仍要单独拼在 URL 里，
http_build_query只管 body
真正容易被忽略的点是：有些接口对参数顺序敏感（比如参与签名），而 http_build_query 按数组键的插入顺序拼接 —— 如果你用 ['b'=>2,'a'=>1]，结果就是 b=2&a=1，和服务端预期不一致就会失败。这时候得先 ksort。