Nginx对不同MIME类型的Gzip压缩开销主要取决于内容是否可压缩、响应体大小及上游是否已压缩，而非类型本身；需按“必压、慎压、禁压、条件启用”四类策略配置，并通过响应头、体积对比和错误日志验证实效性。
直接说结论：Nginx 对不同 MIME 类型的 Gzip 压缩开销，主要不取决于类型本身，而取决于“内容是否可压缩”+“实际响应体大小”+“是否已压缩过”。所谓“按类型设权重”，本质是基于经验对这三者的综合判断，用于规避无效压缩、CPU 浪费和潜在错误。
为什么不能只看 MIME 类型？
MIME 类型只是浏览器和服务器协商如何处理数据的“标签”，不是压缩能力的说明书。比如：
- text/html —— 通常是高冗余文本，gzip 压缩率常达 60%~75%，收益高、开销低；
- application/json —— 同样是纯文本，结构化强，压缩效果好，但若含大量 Base64 编码或加密字段，压缩率会骤降；
- image/jpeg —— 文件本身已是高压缩格式，Nginx 再 gzip 一次，体积基本不变甚至略增，CPU 白耗 2–5ms/请求；
-
image/svg+xml —— 看似是“image/”，实为 XML 文本，未压缩 SVG 压缩率可达 65%，必须纳入
gzip_types； - font/woff2 —— 已用 Brotli 预压缩，再走 gzip 属于典型重复压缩，应严格排除。
压缩开销的三大实际影响因子
真正决定 CPU 和延迟成本的是以下三项，而非后缀或类型字符串：
- 响应体原始熵值：重复字符多、结构规律（如 HTML 标签、JSON 键名）→ 压缩快、收益高；随机字节流（如加密 payload、二进制 blob）→ 压缩慢、收益趋近于零；
- 响应体大小：小于 1KB 的响应，gzip 头部和字典开销可能让总大小反超；大于 1MB 的 JSON，level 6 和 level 9 的 CPU 时间差可达 4 倍，但体积只少 3%～5%；
-
上游是否已压缩：如果后端服务返回时已带
Content-Encoding: gzip，Nginx 默认仍会尝试再压——必须用map检查并跳过，否则造成双重压缩或响应损坏。
推荐的类型分组与压缩策略
按实际压缩性价比，把常见类型分为四类，便于配置和审计：
-
必压组（高收益、低开销）：
text/html、text/css、application/javascript、application/json、text/xml、image/svg+xml； -
慎压组（需结合 size 和 upstream 判断）：
text/plain（可能含日志 dump）、application/xml（可能含大附件 Base64）；建议搭配gzip_min_length 2048+map过滤已压缩响应； -
禁压组（明确无收益）：
image/*（jpeg、png、webp、gif）、video/*、audio/*、application/pdf、font/*（woff、woff2、ttf）、application/x-gzip； -
条件启用组（现代替代方案）：对
text/*和application/json等，可叠加brotli on（需模块支持），比 gzip 多压 15%～20%，且 CPU 更友好；注意不兼容 IE，但多数项目已无需考虑。
验证是否真有效，别只看配置
光写对 gzip_types 不代表生效，必须验证三点：
- 响应头含
Content-Encoding: gzip且Vary: Accept-Encoding； - 相同接口在开启/关闭 gzip 下，响应体大小下降明显（例如 12KB → 4.3KB），而非仅下降几十字节；
- Nginx error log 中无
gzip filter failed或compression ratio异常告警（尤其出现在大 JSON 或含 null 字节的响应中）。
