gzip on 必须显式开启，默认为off，否则gzip_types等配置无效；应置于http/server/location块中，禁用if；gzip_min_length推荐1024~2000字节；避免压缩已高压缩的图片格式；gzip_comp_level 6为平衡点。
gzip on 必须显式开启，否则默认不压缩
很多人改完配置发现没生效，第一反应是浏览器问题，其实 gzip on 默认是 off，Nginx 不会主动启用压缩——哪怕你配了 gzip_types 或 gzip_comp_level，只要没写这行，全白搭。
- 必须放在
http块里（全局生效），或server/location块中按需开启 - 别在
if里用gzip on，Nginx 不支持条件启用 gzip（语法错误） - 改完记得
nginx -t测试配置，再nginx -s reload，别只改不重载
gzip_min_length 设太小反而拖慢响应
设成 1 或 10 字节看似“更彻底”，实际会让极小的响应（比如空 JSON、304 响应体）也进压缩流程，徒增 CPU 开销，还可能因 gzip 头开销导致最终体积变大。
- 推荐从
1024（1KB）起步，文本类资源基本够用 - HTML 页面通常 >2KB，CSS/JS 文件普遍 >5KB，设
2000更稳妥 - 注意：
gzip_min_length只看响应头里的Content-Length，动态生成且没设该头的响应（如某些 PHP 脚本）可能被跳过压缩
gzip_types 别乱加 image/svg+xml 以外的图片类型
image/jpeg、image/png、image/gif 这些本身已是高压缩比格式，再套一层 gzip，99% 情况下体积不变甚至略增，纯属浪费 CPU 和延迟。
- 只加真正受益的类型：
text/html（自动包含）、text/css、application/javascript、application/json、application/xml、image/svg+xml - 别迷信 “
gzip_types *”，它会强制压缩所有 MIME 类型，包括二进制文件，风险高 - 不确定某类型是否该压？用
curl -I --compressed URL看响应头有没有Content-Encoding: gzip，再对比未压缩时的Content-Length
gzip_comp_level 6 是多数场景的甜点值
设成 9 并不意味着“更好”——压缩率只比 6 高 3%~5%，但 CPU 使用率可能翻倍，尤其在并发高时容易成为瓶颈；设成 1 虽快，但压缩收益太低，浪费带宽。
-
gzip_comp_level 6是平衡点：压缩率约 75%，CPU 开销可控 - 静态资源多、CPU 富余？可试
7；老旧服务器或容器资源受限？降为4更稳 - 别在
location里为某个路径单独调高级别，除非你真测出该路径响应体有大量重复文本且对延迟不敏感
gzip_proxied any 在反向代理场景下要谨慎）、以及是否验证了真实响应头。最常被忽略的一点：改完配置后，一定要用真实请求（不是本地 curl）+ 浏览器开发者工具 Network 面板，确认目标资源的响应头里确实出现了 Content-Encoding: gzip。 
