PHP cURL 发送 chunked 编码 POST 请求的关键条件是：不设 Content-Length、启用 CURLOPT_UPLOAD、提供 CURLOPT_READFUNCTION 回调实现流式分块；手动设 Transfer-Encoding 头易出错，file_get_contents 无法可靠模拟，需抓包验证实际请求。
PHP cURL 发送 chunked 编码 POST 请求的关键条件
PHP 默认用 cURL 发起 POST 时不会启用 chunked 编码，除非你显式关闭 Content-Length 并启用分块传输。核心在于：**不设 Content-Length 头 + 设置 Transfer-Encoding: chunked + 使用 curl_setopt($ch, CURLOPT_READFUNCTION, ...) 流式写入**。
常见错误是直接传字符串给 CURLOPT_POSTFIELDS，这会让 cURL 自动计算并设置 Content-Length，chunked 就根本不会触发。
- 必须用
CURLOPT_UPLOAD设为true - 必须 unset 或不设置
Content-Length（cURL 会自动忽略它，但显式设为空更稳妥） - 必须提供
CURLOPT_READFUNCTION回调，每次返回一段数据（包括空段表示结束） -
Transfer-Encoding: chunked通常由服务器识别请求体无长度后自动协商，不建议手动加该头（部分服务端会拒收）
用 curl_setopt 的 CURLOPT_READFUNCTION 实现流式分块
这是最可控的方式：把数据切分成小块，在回调中逐次返回，cURL 自动包装成 chunked 格式发送。适合上传大文件、实时日志推送或对接要求严格 chunked 的 API（如某些 IoT 网关）。
示例逻辑：
立即学习“PHP免费学习笔记（深入）”；
$data = str_repeat("a", 10240); // 模拟 10KB 数据
$offset = 0;
$chunkSize = 2048;
<p>$ch = curl_init("<a href="https://www.php.cn/link/dc076eb055ef5f8a60a41b6195e9f329">https://www.php.cn/link/dc076eb055ef5f8a60a41b6195e9f329</a>");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_UPLOAD, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, ["Content-Type: text/plain"]);
// 关键：不设 Content-Length，让 cURL 走 chunked</p><p>curl_setopt($ch, CURLOPT_READFUNCTION, function($ch, $fd, $length) use ($data, &$offset, $chunkSize) {
$remaining = strlen($data) - $offset;
if ($remaining <= 0) return 0; // 结束
$read = min($chunkSize, $length, $remaining);
$chunk = substr($data, $offset, $read);
$offset += $read;
return $chunk;
});</p><p>$response = curl_exec($ch);
注意：$length 是 cURL 建议本次读多少字节，不是强制；回调返回空字符串或 0 表示 EOF；若返回负数或非字符串，cURL 会中止请求。
为什么 file_get_contents + stream_context_create 很难可靠实现 chunked
PHP 的 stream_context_create 不支持显式声明 chunked 编码，即使你手动加 Transfer-Encoding: chunked 头，file_get_contents 仍会尝试计算并注入 Content-Length（尤其当传入字符串 body 时），导致 HTTP 协议冲突，服务端常返回 400 Bad Request 或直接断连。
只有在配合 php://temp 或 php://memory 流 + 自定义 stream_filter_append 时才可能绕过，但需手动实现 chunked 编码格式（含十六进制长度行、CRLF 分隔等），极易出错且无标准封装。
- 不推荐用
file_get_contents模拟 chunked - 不要手动拼接
"1a\r\n...data...\r\n0\r\n\r\n"—— cURL 已内置编码逻辑，重复实现反而破坏兼容性 - 某些老旧 PHP 版本（如 5.6）对 chunked 支持不完整，建议用 7.4+ 或 8.x
验证是否真的发出 chunked 请求
光看代码不能确认，必须抓包或让接收方回显原始请求头与体。最简单方式是发到 https://www.php.cn/link/dc076eb055ef5f8a60a41b6195e9f329 并检查响应中的 headers.Transfer-Encoding 字段，或用 tcpdump / Wireshark 抓包看请求体是否以十六进制长度开头（如 0a\r\nxxxxxxxxxx\r\n0\r\n\r\n）。
容易被忽略的一点：服务端是否真正按 chunked 解析，取决于它是否开启 chunked transfer decoding 支持。Nginx 默认不处理请求体的 chunked 编码（只处理响应），需配置 underscores_in_headers on; 和自定义模块或改用 Caddy/Envoy 才能透传。所以本地测试成功 ≠ 上线可用，务必在目标环境实测。
