nginx开启gzip压缩需同时配置gzip on和gzip_types，否则仅压缩text/html；推荐类型组合包含text/plain、application/json等，避免重复压缩jpeg/mp4；gzip_static on与gzip on可共存，前者优先服务预压缩.gz文件，后者兜底动态压缩；gzip_comp_level设为6兼顾效率与压缩率，gzip_min_length 1024防小文件负优化，gzip_vary on确保缓存正确分片。
Gzip压缩不是“开了就快”，而是要区分动态内容实时压、静态资源提前压，否则 CPU 白烧、带宽没省、缓存还乱。
gzip on 之后为什么没生效？
常见错误是只写 gzip on，但没配 gzip_types —— Nginx 默认只压缩 text/html，其他如 application/json、application/javascript 全部被忽略。
- 必须显式列出类型，推荐组合：
text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml - 别把
image/jpeg、video/mp4加进去：这些本身已是高压缩格式，再压可能变大或白耗 CPU - 检查
mime.types文件是否被include，否则gzip_types中的类型名会不识别
gzip_static on 和 gzip on 能一起用吗？
能，而且应该一起用：前者处理已存在的 .gz 文件（零 CPU），后者兜底处理动态内容或缺失预压缩文件的情况。
-
gzip_static on仅对请求路径匹配的文件生效（如请求/app.js→ 查找磁盘上app.js.gz） - 它不替代
gzip on：API 返回的 JSON、服务端渲染的 HTML 仍需动态压缩 - 注意顺序：Nginx 不会自动 fallback；若
gzip_static找不到.gz文件，且gzip on已启用，才会走实时压缩
gzip_comp_level 设成 9 真的更好？
不。实测显示级别 6 到 9 的压缩率提升通常不足 5%，但 CPU 时间翻倍甚至更高。
- 级别 1：适合高并发 API 网关，响应快、CPU 轻
- 级别 6：生产环境通用选择，压缩率与开销平衡点
- 级别 9：只建议在构建时预压缩（如 Webpack 的
CompressionWebpackPlugin），别用在 Nginx 动态压缩 - 搭配
gzip_min_length 1024：小于 1KB 的文件压缩后可能反而更大（因 gzip header 占约 20 字节）
为什么加了 gzip_vary on 还被 CDN 缓存错？
因为 gzip_vary on 只加 Vary: Accept-Encoding 头，但部分老旧 CDN 或代理会忽略这个头，或缓存未区分编码版本。
- 确认客户端请求头含
Accept-Encoding: gzip（现代浏览器默认带） - 检查响应头是否真有
Vary: Accept-Encoding（用curl -I验证） - CDN 层需显式开启「基于 Vary 头缓存分片」功能，否则所有用户拿到同一份未压缩缓存
- 若用
gzip_static，Nginx 不会改写Vary头——它发的是原始.gz文件，Content-Encoding 由文件本身决定
最易被忽略的一点：静态资源预压缩（.gz 文件）必须和源文件时间戳一致，否则某些 Nginx 版本会拒绝使用它；用 touch -r app.js app.js.gz 同步时间可避坑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
