PHP内置gzip压缩失效的典型表现是浏览器Network面板中Content-Encoding为空且响应体积未减小，主因是反向代理绕过ob_gzhandler或提前输出导致缓冲失效；需确保ob_start('ob_gzhandler')在任何输出前调用，并避免Web服务器重复启用gzip。
PHP内置gzip压缩失效的典型表现
浏览器Network面板里看到Content-Encoding没值，响应体积没变小，甚至Content-Length还变大了——这不是没启用，是启用了但被中间层干掉了。常见于Nginx/Apache反代后，PHP的ob_gzhandler被绕过；或者输出前已调用header()发了状态码，导致gzip缓冲无法接管。
- 检查是否在
ob_start()前就输出了空格、BOM或echo - 确认Web服务器没开启自己的gzip（比如Nginx的
gzip on），否则PHP层压缩会冲突，反而触发“double gzip”报错 -
ini_set('zlib.output_compression', '1')在CLI模式下无效，只对Web SAPI生效
用ob_gzhandler做最小侵入式启用
不改服务器配置、不依赖扩展，纯PHP代码控制，适合共享主机或临时调试。它本质是output buffer的一个回调处理器，自动判断客户端是否支持gzip或deflate，并选择合适算法。
- 必须在任何输出之前调用：
ob_start('ob_gzhandler')，放在<?php第一行最稳妥 - 不建议和
ob_deflate_handler混用——PHP不自带后者，容易报Warning: ob_start(): failed to create buffer - 若API返回JSON，注意
Content-Type要显式设为application/json; charset=utf-8，否则部分旧客户端可能拒绝解压
ob_start('ob_gzhandler');
header('Content-Type: application/json; charset=utf-8');
echo json_encode(['data' => range(1, 1000)]);
Nginx+PHP-FPM环境下真正生效的配置组合
单靠PHP层压缩在高并发时CPU压力大，且无法压缩静态资源。必须让Nginx接管主体压缩任务，PHP只负责动态内容兜底。
- Nginx配置中关闭PHP相关路径的gzip：
location ~ \.php$ { gzip off; ... }，避免和PHP的ob_gzhandler打架 - 全局开启Nginx gzip，但排除已压缩的二进制类型：
gzip_types application/json text/plain text/css application/javascript; - PHP-FPM的
php.ini里关掉zlib.output_compression，防止和Nginx重复压缩导致响应头Vary: Accept-Encoding混乱
验证压缩是否真起作用的关键检查点
别只信浏览器DevTools里一个Content-Encoding: gzip，很多代理会悄悄解压再转发，你以为压了，其实链路里早被还原了。
立即学习“PHP免费学习笔记（深入）”；
- 用
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/api看响应头有没有Content-Encoding: gzip和Vary: Accept-Encoding - 对比
curl --compressed和curl的Content-Length数值，差30%以上才算有效 - 如果用CDN，确认其缓存策略是否保留
Vary头——Cloudflare默认会删掉，导致gzip版本被非gzip用户命中
压缩不是越狠越好，gzip_comp_level 6在Nginx里是平衡点，PHP的ob_gzhandler没有级别控制，它用zlib默认级，够用。真要调参，优先动Nginx，别在PHP里硬扛。
