17370845950

PHP 8.4 应交由 Nginx/Apache 处理压缩，因 zlib.output_compression 已弃用且无法条件启用，ob_gzhandler 易失效并干扰 header；Nginx gzip 配置更高效、可控、兼容 HTTP/2 与 CDN。

PHP 8.4 默认不启用输出压缩，zlib.output_compression 仍可用但已被标记为“deprecated”，且 ob_gzhandler 在 CLI SAPI 下失效；真正可靠、符合现代部署习惯的做法是交由 Web 服务器（如 Nginx / Apache）处理 gzip/brotli 压缩。

为什么不应依赖 zlib.output_compression 或 ob_gzhandler

PHP 8.4 中 zlib.output_compression 虽未被移除，但官方文档已明确标注为 deprecated，未来版本会删除；它强制对所有响应启用压缩，无法按 MIME 类型或状态码条件启用，且与 HTTP/2 的流式传输、缓存策略冲突。而 ob_gzhandler 依赖输出缓冲层级，在启用了 output_buffering = Off 或使用 Swoole/Swoft 等协程框架时极易失效，还会干扰 header() 发送逻辑。

• 开启 zlib.output_compression 后，Content-Length 可能计算错误，导致 Chrome/Firefox 截断响应
• ob_gzhandler 无法识别客户端是否支持 br（brotli），只能 fallback 到 gzip，且不兼容 Transfer-Encoding: chunked
• PHP 层压缩会增加 CPU 开销，尤其在高并发 JSON API 场景下，不如让 Nginx 异步压缩更高效

Nginx 配置 gzip 压缩（推荐方案）

这是 PHP 8.4 应用最稳定、最可控的压缩方式：完全绕过 PHP 输出层，由 Nginx 根据请求头、MIME 类型和响应大小动态决定是否压缩。

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types application/json text/plain text/css text/javascript application/javascript text/xml application/xml application/xml+rss text/javascript;
gzip_comp_level 6;
gzip_proxied any;

• gzip_vary on 必须开启，否则 CDN 或代理可能缓存未压缩版本
• gzip_min_length 1024 避免对小响应（如空 JSON {}）徒增开销
• gzip_types 显式列出类型，不建议用 text/* 通配，防止压缩二进制文件（如 SVG 字体）出错
• 若需 brotli，需编译 Nginx 加载 ngx_brotli 模块，并配置 brotli on; 替代 gzip

PHP 8.4 中手动触发压缩（仅限特殊场景）

仅当必须由 PHP 控制压缩时机（如生成大报表后直接输出、或调试阶段验证压缩效果），才考虑手动调用 gzencode() 并设置头：

 array_fill(0, 1000, ['id' => 1])]);
$compressed = gzencode($data, 6);

header('Content-Encoding: gzip');
header('Vary: Accept-Encoding');
header('Content-Length: ' . strlen($compressed));
echo $compressed;
?>

• 必须手动发送 Content-Encoding 和 Vary 头，否则浏览器无法解压
• 不能混用 ob_start() 和 gzencode()，否则会双重压缩或 header 冲突
• 该方式绕过所有 PHP 输出缓冲机制，register_shutdown_function() 和异常处理器无法捕获后续错误
• 不适用于框架（Laravel/Symfony），因其响应生命周期由 HttpKernel 管理，应改写 Response 对象的 send() 方法

真正要注意的是：Nginx 的 gzip_disable 默认禁用对 MSIE 6 的压缩，若你还在支持 IE6，得显式清空该指令；另外，PHP-FPM 的 fastcgi_buffer_size 和 fastcgi_buffers 必须大于压缩后响应体，否则 Nginx 会回退到临时文件中转，大幅降低性能。