核心目标是减少html、css、js等文本类资源传输体积，通常压缩60%–90%；需限定text/css、application/json等文本mime类型，设gzip_min_length 1024、comp_level 5，开启gzip_vary on，并验证content-encoding: gzip生效。
资源优化中配置 Gzip 压缩，核心目标是减少 HTML、CSS、JS 等文本类资源的传输体积，通常能压缩掉 60%–90% 的原始大小。关键不是“全开”，而是选对范围、设好阈值、避开误区。
只压缩适合的文件类型
Gzip 对已压缩的二进制文件（如 JPG、PNG、GIF、WEBP、MP4）基本无效，反而浪费 CPU。必须严格限定为文本类 MIME 类型：
- 必加项：text/plain、text/css、text/javascript、application/javascript、application/json、text/xml、application/xml、application/xml+rss、image/svg+xml
- 不建议加：application/octet-stream、image/*（除 svg+xml 外）、font/*、video/*、audio/*
- 注意：text/js 不是标准 MIME 类型，应使用 text/javascript 或 application/javascript
合理设置压缩触发条件
太小的文件（比如几十字节的空 CSS 或 inline script）压缩后可能反而变大，还增加 CPU 开销：
- gzip_min_length 推荐设为 1024（即 1KB），低于此值不压缩
- gzip_comp_level 建议用 5 或 6：级别 1 太弱，9 级 CPU 占用高但收益微乎其微
-
gzip_buffers 默认
4 16k足够；若站点有较大 JS/CSS（>64KB），可调为8 16k
确保客户端与缓存链路兼容
光压缩还不够，要让浏览器和中间代理正确识别和处理压缩响应：
-
gzip_vary on 必须开启——它会在响应头添加
Vary: Accept-Encoding，避免 CDN 或反向代理把压缩版缓存给不支持 gzip 的旧设备 - gzip_http_version 1.1 推荐设置，因 HTTP/1.0 对压缩支持不一致
- gzip_disable "MSIE [1-6]\." 可选，用于屏蔽极老 IE（现基本可省略）
- gzip_proxied any 若 Nginx 前面还有 CDN 或负载均衡，建议开启，确保代理请求也走压缩
验证是否真正生效
配置完别急着上线，用工具确认效果：
- 浏览器开发者工具 → Network 标签 → 刷新页面 → 找一个 JS 或 CSS 文件 → 查看 Response Headers 中是否有
Content-Encoding: gzip - 命令行验证：
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/app.js，响应头中应含Content-Encoding: gzip和更小的Content-Length - 对比压缩前后大小：在 Network 面板看 “Size” 列（传输体积） vs “Content” 列（解压后体积）
