nginx gzip压缩需在http块中配置，开启gzip并显式指定text/html、application/json、application/x-httpd-php等mime类型，设置min_length为1024、level为5、vary为on，可减少60%–90%文本资源体积。
直接在 Nginx 的 http 块里加几行配置就能生效，核心是只压该压的文本类资源，避开图片、字体等已压缩格式，体积通常能减少 60%–90%。
必须放在 http 块中
配置必须写在 http { } 全局块内，不是 server 或 location 里。否则多数场景下不生效，尤其是 PHP 页面或 API 接口容易漏压。
-
gzip on;—— 开启开关，没这句等于没配 -
gzip_min_length 1024;—— 小于 1KB 的响应不压，避免空 JSON 或短提示反而变大 -
gzip_comp_level 5;—— 级别 5 是实测平衡点：比 1–3 省 15%–25% 体积，CPU 开销仍可控；设成 9 很少必要 -
gzip_vary on;—— 强制加Vary: Accept-Encoding响应头，防止 CDN 或代理缓存错乱
明确指定要压缩的 MIME 类型
不能依赖默认行为，gzip_types 必须显式列出，尤其注意包含动态内容类型：
- 基础文本类：
text/plain text/css text/javascript text/xml application/json - HTML 和 PHP 页面：
text/html application/x-httpd-php（很多教程漏掉后者，导致 PHP 输出不压缩） - 现代常用格式：
application/javascript image/svg+xml application/xml+rss - 不建议加：
image/jpeg image/png font/woff2—— 这些本身已高压缩，再套 gzip 几乎不减体积，纯耗 CPU
验证是否真正生效
改完配置后 reload，用 curl 检查真实响应头：
- 执行：
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/style.css - 看返回头里是否有：
Content-Encoding: gzip - 若没有，常见原因：MIME 类型没列全、配置位置错了、或文件实际小于 1KB
额外注意点
如果用了反向代理（比如前端是 CDN 或 Nginx 转发到后端服务），建议加上：
-
gzip_proxied any;—— 让代理过来的请求也走压缩逻辑 -
gzip_http_version 1.1;—— 避免 HTTP/1.0 客户端兼容问题 -
gzip_disable "MSIE [1-6]\.";—— 兼容极老 IE（现在基本可省）
