php curl 默认不自动解压 gzip 响应，需显式设置 curlopt_encoding 为 'gzip' 由 libcurl 透明解压；手动解压可用 gzdecode()，但需确保 php ≥ 5.4 且响应为标准 gzip 格式。
PHP cURL 默认不自动解压 gzip 响应
PHP 的 curl_exec() 默认不会自动解压 gzip 编码的响应体，即使服务器返回了 Content-Encoding: gzip，你拿到的仍是压缩后的二进制数据——直接 echo 或 json_decode() 会失败，常见报错如 JSON_ERROR_SYNTAX 或显示乱码。
根本原因：cURL 扩展本身不处理编码解压，它只负责传输；解压需手动开启或由 PHP 层后置处理。
启用 gzip 解压的两种可靠方式
推荐优先使用 cURL 自带的 CURLOPT_ENCODING 选项，它由 libcurl 底层支持，稳定且无需额外依赖：
- 设置
curl_setopt($ch, CURLOPT_ENCODING, 'gzip')，libcurl 会自动请求Accept-Encoding: gzip并在收到 gzip 响应时透明解压 - 该选项也支持
'deflate'或空字符串（''）表示接受所有服务端支持的编码 - 注意：不要手动设置
Accept-Encoding请求头，否则可能覆盖CURLOPT_ENCODING的行为
备选方案（不推荐）：手动解压。仅在无法控制 cURL 行为时用，需先禁用自动解压（CURLOPT_ENCODING 设为 ''），再对响应体调用 gzdecode() ——但要注意 gzdecode() 要求 PHP ≥ 5.4，且响应必须是标准 gzip 格式（不是 raw deflate）。
立即学习“PHP免费学习笔记（深入）”；
验证是否真启用了 gzip 压缩
别只看响应头里有没有 Content-Encoding: gzip，重点确认最终拿到的数据是否已解压：
- 打印
strlen($response)对比未开启CURLOPT_ENCODING时的长度，明显变长说明解压生效 - 用
mb_detect_encoding($response, ['UTF-8'], true)检查是否为可读文本编码 - 若仍乱码，检查服务器是否实际返回了 gzip（有些 CDN 或代理会移除
Content-Encoding头但保留压缩体）
一个简单验证示例：
$ch = curl_init('https://httpbin.org/gzip');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_ENCODING, 'gzip'); // 关键
$response = curl_exec($ch);
var_dump(strlen($response) > 100); // true 表示已解压为明文
curl_close($ch);
容易被忽略的兼容性细节
某些旧版 libcurl（如 CentOS 6 自带的 7.19.x）对 CURLOPT_ENCODING 支持不完整，即使设置了也可能不触发解压。此时需升级系统 libcurl 或改用 gzdecode() 手动处理。
另一个隐藏坑：CURLOPT_ENCODING 在 PHP-FPM 模式下若启用了 opcache，偶尔会因缓存导致首次请求不生效——建议在关键请求前加 opcache_reset() 排查（仅调试用，勿上线）。
gzip 压缩真正起效的前提，是目标服务器明确支持并返回了压缩响应；如果对方没配 gzip，设了 CURLOPT_ENCODING 也没用，只会走原始响应流程。
