正确写法是：curl_setopt($ch, CURLOPT_POSTFIELDS, $json_str)传字符串、CURLOPT_HTTPHEADER手动设'Content-Type: application/json'、CURLOPT_POST显式设true；否则Content-Type被覆盖导致后端收不到数据。
curl_post_json 函数怎么写才不丢数据
PHP 原生 curl 发 JSON 数据，核心是设对三个东西：请求头、JSON 字符串、CURLOPT_POSTFIELDS 的值类型。很多人用 json_encode($arr) 后直接塞进 curl_setopt($ch, CURLOPT_POSTFIELDS, $json_str)，却忘了关掉 CURLOPT_POST 的自动表单编码逻辑——这会导致 Content-Type 被强行覆盖成 application/x-www-form-urlencoded，后端收不到 json_decode(file_get_contents('php://input'))。
正确做法：
-
curl_setopt($ch, CURLOPT_POSTFIELDS, $json_str)—— 传字符串，不是数组 -
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/json; charset=utf-8'])—— 手动指定，不依赖 curl 自动推断 -
curl_setopt($ch, CURLOPT_POST, true)—— 必须显式开启 POST 模式（哪怕已设POSTFIELDS）
file_get_contents + stream_context_create 能不能替代 curl
能，但要注意默认行为差异：file_get_contents 不发 POST 请求，必须靠 stream_context_create 构造上下文。它更轻量，适合简单调用；但没 curl 灵活（比如无法细粒度控制超时、重试、SSL 验证级别）。
关键配置项：
立即学习“PHP免费学习笔记（深入）”；
-
'http' => ['method' => 'POST']—— 必须显式声明方法 -
'header' => "Content-Type: application/json\r\n"—— 换行符必须是\r\n，单\n会出错 -
'content' => $json_str—— 直接放 JSON 字符串，不是数组
错误示例：'content' => json_encode($arr) 却漏了 header，结果服务端收到空体或 415 错误。
为什么 file_get_contents 收不到响应体，只返回 false
常见于 HTTPS 接口未验证证书，或目标服务返回非 2xx 状态码时被静默截断。默认情况下，file_get_contents 遇到 HTTP 错误（如 400、500）会直接返回 false，不抛异常也不给响应体。
解决办法：
- 加
'ignore_errors' => true到 context 中，强制返回响应内容（含错误状态码的 body） - 检查
$http_response_header全局变量，它存着原始响应头，可用来判断状态码 - HTTPS 场景下，临时加
'ssl' => ['verify_peer' => false, 'verify_peer_name' => false]（仅调试，上线必须配好 CA）
用 Guzzle 发 JSON 是不是更稳
是，尤其在复杂场景下。Guzzle 默认把数组当表单发，要发 JSON 必须显式用 json 选项：
$client = new \GuzzleHttp\Client();
$response = $client->post('https://api.example.com/v1/data', [
'json' => ['name' => 'foo', 'id' => 123]
]);
它自动设好 Content-Type、序列化、处理编码，还内置重试和连接池。但如果你只是偶尔调一个接口，引入 Guzzle 反而增加部署负担——这时候手写 curl 更干净。
真正容易被忽略的是：Guzzle 的 json 选项只接受数组或对象，传字符串会报错；而 body 选项才接受字符串，但不会自动设 header。
