nginx中gzip_types配置的是响应头content-type的mime类型，决定哪些文本类资源被gzip压缩；必须包含text/html、text/plain、text/css、application/javascript、application/json；避免image/、video/等二进制类型。
nginx 中 gzip_types 配置的是响应头 Content-Type 的 MIME 类型，不是文件后缀，也不是通配符匹配。它决定哪些类型的内容会被启用 Gzip 压缩，核心原则是：只对文本类、可压缩性强的资源启用，避开已压缩的二进制格式。
必须包含的基础类型
这些类型压缩收益高、兼容性好，属于实际部署中最常启用的：
- text/plain：纯文本（如 API 返回的 raw 数据、日志片段）
- text/css：CSS 文件，体积通常较大，压缩比明显
-
application/javascript：现代标准 JS 类型，务必包含（旧式
text/javascript可选，但非必需） - application/json：API 接口主流返回格式，结构规整，压缩效果极佳
-
text/html：关键项！
gzip_types是覆盖式配置，一旦设置就会取代默认值（仅text/html），漏掉它会导致 HTML 页面完全不压缩
推荐补充的实用类型
根据业务场景可酌情加入，注意确认后端或 Nginx 实际输出的 Content-Type 与之严格一致（含大小写、无多余空格）：
- application/xml 和 text/xml：RSS、SOAP 或传统 XML 接口
- application/vnd.api+json：JSON:API 规范响应
- image/svg+xml：SVG 是文本格式，压缩后体积显著减小
-
application/x-yaml 或 text/markdown：若后端明确返回这类类型，且内容为纯文本，可加入（需先在
mime.types中映射对应后缀）
明确要避免的类型
加了不仅无效，还浪费 CPU，甚至引发解析问题：
-
image/*（如
image/jpeg、image/png）、video/*、audio/*：本身已是高压缩率二进制格式，Gzip 几乎不减体积，反而增加延迟 - application/octet-stream：语义模糊，可能包裹任意二进制内容，强制压缩易破坏数据
-
font/*（如
font/woff2）：WOFF2 等字体格式自带压缩，再套 Gzip 无益；若用旧版 WOFF，可测试后再定，一般也不建议
配置生效的关键细节
写法和验证环节容易出错，需特别注意：
- 多个类型用空格分隔，整条指令结尾用分号（
;），不是每个类型后加分号 - 修改后必须执行
nginx -t && nginx -s reload，重启进程不等于重载配置 - 验证是否生效：用浏览器 DevTools 查看 Network → Response Headers → 是否有
Content-Encoding: gzip - 动态生成内容（如 SSI、Edge 注入）需确保最终响应头中的
Content-Type字符串与gzip_types中声明的**完全一致**，大小写敏感
