PHP用gzip压缩响应体并非万能，需满足服务端配置、客户端支持、内容类型等条件，且Web服务器（如Nginx）处理更可靠；手动压缩须显式设置Content-Encoding、避免二次压缩并删除Content-Length。
PHP 用 gzip 压缩响应体，确实能显著减小传输量，但**不是所有场景都该开，也不是开了就一定生效**——关键看服务端配置、客户端支持、响应内容类型和是否已由 Web 服务器代劳。
PHP 自己调用 ob_gzhandler 的适用场景有限
这个函数只在满足全部条件时才起作用：ob_start() 必须先调用；PHP 编译时启用了 --with-zlib；客户端请求头带 Accept-Encoding: gzip；且输出未被其他输出缓冲处理器拦截。
常见误用是直接写：
ob_start('ob_gzhandler');
结果发现没压缩，原因可能是：
立即学习“PHP免费学习笔记（深入）”；
- Web 服务器（如 Nginx/Apache）已开启
gzip，PHP 层再开会导致双重压缩或报错 - 响应头已被发送（比如提前
echo或 header() 调用），ob_gzhandler失效 - 输出内容太短（默认 zlib 小于 20 字节不压缩），或含二进制数据（如图片 base64）导致压缩失败
Nginx/Apache 开启 gzip 比 PHP 更可靠
绝大多数生产环境应交由 Web 服务器处理压缩，PHP 只管生成原始响应。Nginx 示例配置：
gzip on;<br>gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
注意点：
-
gzip_types必须显式包含application/json，否则 API 接口返回的 JSON 不会压缩 - 避免对
text/html启用gzip_vary on同时又用 CDN，可能引发缓存歧义 - PHP-FPM 下若启用
fastcgi_buffering off，可能绕过 Nginx gzip，需检查fastcgi_cache和gzip的协作顺序
手动压缩 JSON 接口要小心 Content-Length 和 Header 冲突
如果必须 PHP 层压缩（比如某些微服务直连、无 Web 服务器中转），不要仅依赖 ob_gzhandler，而应显式控制：
if (strpos($_SERVER['HTTP_ACCEPT_ENCODING'] ?? '', 'gzip') !== false) {<br> header('Content-Encoding: gzip');<br> $data = json_encode($payload);<br> echo gzencode($data, 6); // 第二参数是压缩级别，1~9，6 是默认平衡点<br> exit;<br>}
此时务必注意：
- 不能同时用
ob_gzhandler+gzencode，否则二次压缩，客户端解不开 - 必须手动发
Content-Encoding: gzip，否则浏览器当明文解析 - 别忘了删掉
Content-Length头（或让 Web 服务器重算），否则长度对不上会截断
最常被忽略的是：很多所谓“开启 gzip”只是改了 PHP 配置里的 zlib.output_compression，但它只影响 CLI 模式或未启用 output buffering 的情况，Web SAPI 下基本无效；真正起效的永远是 Web 服务器层或显式 gzencode + 正确 header 组合。
