根本原因是请求体编码与目标接口期望编码不一致，PHP 不自动转码；须确保数据为 UTF-8、Content-Type charset 与实际 payload 严格一致，并全链路统一 UTF-8。
PHP 模拟 POST 请求时出现中文乱码，根本原因不是 cURL 或 file_get_contents 本身的问题，而是请求体编码与目标接口期望编码不一致，且 PHP 默认不自动处理字符集转换。
curl_setopt 设置 CURLOPT_POSTFIELDS 前必须确保字符串是 UTF-8 编码
很多老项目用 GBK 存数据库或文件，直接把 $_POST 或数据库查出的 GBK 字符串塞进 CURLOPT_POSTFIELDS，服务端收到的就是乱码字节流。PHP 不会帮你转码，它只负责原样发送。
- 用
mb_convert_encoding($data, 'UTF-8', 'GBK')显式转码，别依赖iconv('GBK', 'UTF-8', $data)（遇到非法字节会失败） - 如果数据来自 MySQL，确认连接层已设
SET NAMES utf8mb4，否则mysqli_fetch_assoc()返回的仍是 latin1 编码的乱码 - 对数组形式的 POST 数据，需递归转码；简单起见，建议先
json_encode($arr, JSON_UNESCAPED_UNICODE)再发，服务端用json_decode(file_get_contents('php://input'))接收
header 中 Content-Type 的 charset 必须和实际 payload 编码严格一致
写了 Content-Type: application/x-www-form-urlencoded; charset=utf-8 却发 GBK 字节，等于主动误导对方解码器——这是最常被忽略的「假声明」陷阱。
- 表单 URL 编码（
application/x-www-form-urlencoded）本身不携带编码信息，charset参数纯属 HTTP 建议，服务端可忽略；但 Laravel、Spring 等框架会按此解析，不匹配就丢弃或报错 - 发 JSON 时，
Content-Type: application/json; charset=utf-8是必须的，且json_encode()输出默认就是 UTF-8，无需额外转码 - 避免写
charset=gbk：现代接口基本不支持，且 PHP cURL 对非 UTF-8 charset 无特殊处理
file_get_contents + stream_context_create 发送 POST 时的编码陷阱
用 file_get_contents() 模拟 POST 看似简洁，但 http_build_query() 默认按 ASCII 处理非英文字符，不转义也不编码，直接拼接会导致 500 错误或乱码。
立即学习“PHP免费学习笔记（深入）”；
- 务必用
http_build_query($data, '', '&', PHP_QUERY_RFC3986)，强制 RFC3986 编码（支持 UTF-8 字节直接 percent-encode） - 若
$data含中文键名（如['用户名' => '张三']），http_build_query会失败，此时应改用urlencode()手动拼接，或统一用 JSON 格式 -
stream_context_create()的content选项必须是 UTF-8 字节流，不能是 GBK 字符串；否则即使 header 写了 utf-8，实际发出去的仍是乱码二进制
真正麻烦的不是怎么发，而是你永远不知道对方接口底层用什么编码读取 raw body——有的用 mb_convert_encoding(file_get_contents('php://input'), 'UTF-8', 'auto')，有的硬写 iconv('GB2312', 'UTF-8', $raw)，还有的直接 utf8_encode()（仅对 ISO-8859-1 有效）。所以最稳的方式：自己控住源头，全链路用 UTF-8，别给对方留猜的机会。