PHP发送gzip压缩POST请求需手动压缩请求体并设Content-Encoding: gzip头，服务端须从php://input读取后用gzdecode()解压；通常应优先启用cURL自动解压响应而非压缩请求。
PHP cURL 发送 POST 时启用 gzip 压缩请求体
PHP 默认不会对 POST 请求体做压缩，服务端也通常不期望接收压缩过的请求体——除非明确约定。如果你控制着服务端（比如另一个 PHP 接口），且双方协商使用 Content-Encoding: gzip，那才需要手动压缩请求体并设置对应头。
常见错误是直接给 curl_setopt($ch, CURLOPT_ENCODING, 'gzip')，这只会让 cURL **自动解压响应体**，对请求体毫无影响。
- 用
gzencode()或gzdeflate()压缩原始数据（注意：gzencode()包含 gzip header，更通用；gzdeflate()是 raw deflate，兼容性差） - 手动设置
Content-Encoding: gzip和Content-Length（cURL 不会自动重算压缩后长度） - 禁用 cURL 自动添加的
Accept-Encoding头（避免干扰服务端判断） - 确保服务端能正确读取并解压
php://input（不能依赖$_POST，因为 PHP 不自动解压请求体）
服务端如何安全解压 PHP 的 gzip POST 数据
PHP 不会自动解压带 Content-Encoding: gzip 的请求体，$_POST 为空或解析失败是正常现象。必须从 php://input 读取原始流并手动解压。
- 先检查
$_SERVER['HTTP_CONTENT_ENCODING'] === 'gzip' - 用
file_get_contents('php://input')获取原始字节 - 用
gzdecode()解压（PHP ≥ 5.4；若用gzencode()压缩，则必须用gzdecode()，不可混用gzuncompress()） - 解压失败时要捕获警告（
@gzdecode()或 try/catch +error_get_last()），避免空请求体导致致命错误 - 解压后建议用
json_decode($data, true)或parse_str($data, $output)进一步处理，取决于原始格式
替代方案：用 cURL 自动压缩响应，而非压缩请求
绝大多数场景下，“压缩 POST 请求”是过度设计。真正有收益的是让服务端返回压缩响应（如 JSON），由 cURL 自动解压——这才是 CURLOPT_ENCODING 的正确用途。
立即学习“PHP免费学习笔记（深入）”；
- 设置
curl_setopt($ch, CURLOPT_ENCODING, '')（传空字符串表示接受所有支持的编码） - cURL 会自动加
Accept-Encoding: gzip, deflate头 - 服务端返回
Content-Encoding: gzip时，cURL 在返回前自动解压，你拿到的就是明文响应体 - 无需改动服务端逻辑，无兼容风险，性能提升明显，且是 HTTP 标准实践
调试时容易忽略的传输细节
用 curl_setopt($ch, CURLOPT_HEADER, true) 查看实际发出的请求头，确认：Content-Encoding 是否存在、Content-Length 是否匹配压缩后字节数、是否意外携带了 Expect: 100-continue（可能阻塞小请求）。
-
gzencode()输出比原文长约 18 字节（gzip header + trailer），strlen()必须作用于压缩后结果 - 若用
http_build_query()构造表单数据，压缩前确保没多余空格或换行（尤其 Windows 换行符 \r\n 可能破坏解压） - 某些 CDN 或 WAF（如 Cloudflare）会丢弃或改写
Content-Encoding请求头，测试务必直连后端 - 不要在压缩后还设
application/x-www-form-urlencoded—— 应改为application/octet-stream或自定义类型（如application/gzip+json），避免中间件误解析
