gzip_comp_level最佳平衡点为4–6级：级别4压缩率约60%、适合CPU敏感场景；级别5约68%、推荐新站点默认；级别6达75%、为Nginx默认值；7–9级对已压缩资源无效且CPU开销剧增。
压缩调优不是只调一个 gzip_comp_level 就完事。它本质是 CPU、内存、带宽三者之间的动态平衡——压得狠，带宽省了，CPU却可能飙高；压得太轻，用户等得久，服务器还白耗资源。关键在“按需压缩”和“提前准备”。
压缩级别怎么选：6 是默认起点，不是万能解
级别 1～9 不是线性收益。实测表明：
- 级别 5～6 压缩率约 60%～70%，CPU 开销温和，适合绝大多数文本类资源（HTML/CSS/JS/JSON）
- 级别 9 比级别 6 多压 3%～5%，但 CPU 时间翻 4～5 倍，响应延迟反而上升
- 静态资源若已预压缩（如 .gz 文件存在），可设为 1 或关闭实时压缩，把 CPU 省下来干别的
哪些文件该压、哪些坚决不压
盲目开启 gzip_types 是性能陷阱。必须按资源特性分类处理：
- 强烈推荐压缩：text/plain、text/css、application/javascript、application/json、text/xml —— 压缩率 60%～85%，开销极低
- 谨慎启用：application/xml+rss、text/javascript（旧式 MIME）—— 需确认客户端兼容性
- 禁止压缩：image/jpeg、image/png、video/mp4、.zip/.pdf —— 压缩率趋近于 0，反而增加 CPU 和延迟
小文件不压，大文件才值得压
用 gzip_min_length 过滤掉“得不偿失”的压缩请求：
- 设为 256 或 1024 字节（推荐 1024）：避免对 <1KB 的 HTML 片段、空响应体做压缩，这类操作常导致输出变大
- 注意：Nginx 默认值是 20 字节，极易引发负优化，上线前务必覆盖
- 搭配
gzip_buffers 16 8k可提升中等体积文件的缓冲效率，减少内存拷贝
用预压缩代替实时压缩
对不变的静态资源（如构建产物），让压缩离线完成：
- 启用
gzip_static on：Nginx 优先查找同名 .gz 文件（如app.js.gz），直接返回，零 CPU 开销 - 配合构建工具（Webpack/Vite）生成 .gz 和 .br（Brotli）文件，再启用
brotli_static on - 注意：需确保文件修改后 .gz 同步更新，否则缓存会返回过期压缩内容
不复杂但容易忽略
