Hyperf 不处理 HTTP 层 Gzip 压缩，依赖 Swoole 或 Nginx 实现：Swoole 层需 ≥5.0 且启用 zlib，配置 http_compression；Nginx 层为生产首选，需设置 gzip 相关指令并验证响应头。
Hyperf 本身不处理 HTTP 层的 Gzip 压缩，它依赖 Swoole 或前置代理（如 Nginx）完成响应体压缩。直接在 Hyperf 应用层开启 Gzip 并不能提升单机访问速度，反而可能因重复压缩或协程阻塞引入开销。真正有效且推荐的方式是分层配置：Swoole 内置压缩用于纯 CLI 启动场景，Nginx 压缩用于标准反向代理部署。
Swoole 层启用 Gzip（适合无 Nginx 直连场景）
Hyperf 运行在 Swoole 上时，可通过 server.php 配置启用响应压缩：
- 在
config/autoload/server.php的settings中添加：'http_compression' => true, 'http_compression_level' => 6,
- 确保 Swoole ≥ 5.0 且编译时启用了 zlib（
--enable-http2 --with-zlib），否则该设置无效 - 此压缩仅对
text/*、application/json等 MIME 类型生效，不压缩二进制内容（如图片、PDF）
注意：Swoole 的压缩发生在协程内，若并发高、响应体大，会略微增加 CPU 占用；建议配合 output_buffering 控制缓冲行为，避免小包频繁 flush。
Nginx 层配置 Gzip（生产环境首选）
绝大多数 Hyperf 生产部署都使用 Nginx 反向代理，此时应由 Nginx 统一处理压缩，更稳定、可控且不占用 PHP 协程资源：
- 在 Nginx 的
location块中加入：gzip on; gzip_types application/json text/plain text/css text/js text/xml text/javascript application/javascript application/x-javascript application/xml+rss application/atom+xml; gzip_vary on; gzip_min_length 1024; gzip_comp_level 5; gzip_disable "msie6";
- 关键点：
gzip_vary on保证缓存兼容性；gzip_min_length避免压缩过小响应（如空 JSON{}）；gzip_comp_level 5是性能与体积的较好平衡点
验证是否生效：用 curl -H "Accept-Encoding: gzip" -I http://your-domain/api/test 查看响应头是否含 Content-Encoding: gzip。
不要混淆请求体 Gzip（客户端发来的压缩数据）
Hyperf 默认不自动解压客户端发送的 Gzip 请求体（如 Content-Encoding: gzip）。若第三方系统推送压缩数据，需手动处理：
- 在中间件中读取原始 body 并解压：
$raw = $request->getBody()->getContents(); $body = gzdecode($raw);
- 或通过 Nginx 配置
gzip_proxied any;和gunzip on;实现透明解压（需 Nginx ≥ 1.3.13）
这类压缩不影响「访问速度」，只影响服务端能否正确解析请求。
不复杂但容易忽略
