最稳妥起点是gzip_comp_level设为4–6，但需依业务类型选级：官网/SSR用6，API网关用3，边缘节点用5；同步配好min_length、types和vary；务必验证响应头、压缩率及CPU负载。
直接设 gzip_comp_level 为 4–6 是最稳妥的起点，但真正平衡 CPU 和压缩率，关键不在“填哪个数”，而在匹配业务类型、约束压缩范围、验证实际效果。
按内容和流量特征选 level
不同服务对响应速度和带宽敏感度不同，不能统一用 6：
- 面向用户的官网、CMS、SSR 页面：推荐 level 6，HTML 压缩率常达 70%，JS/CSS 约 65%，实测 QPS 和体积节省较稳
- API 网关或高频 JSON 接口：用 level 3 更合适，压缩率仍有 40%+，CPU 占用低，高并发下延迟更可控
- 边缘节点、容器化部署或新上线项目：level 5 是友好折中，压缩率约 68%，CPU 开销比 level 6 明显降低
别只调 level，三件事必须同步配好
单改压缩级别就像只踩油门不控散热，容易过热或白压：
-
gzip_min_length 1024：跳过小于 1KB 的响应（如
{"ok":true}），避免小包压缩反增开销 -
gzip_types 精准限定：只开
text/html、application/json、application/javascript、text/css等文本类型；明确关掉image/*、video/*、.woff2—— 对 JPEG 再压不仅无效，还可能变大 - gzip_vary on：必须开启，否则 CDN 或反向代理可能缓存未压缩版本，导致部分用户看到空白页或乱码
验证是否真生效，不能只看配置
调完不验证，等于没调。重点查这三项：
- 用
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/test.js，确认响应头含Content-Encoding: gzip - 浏览器 Network 面板里对比 “Size”（传输体积）和 “Content”（原始体积），算出真实压缩率
- 用
htop观察 nginx 进程 CPU 使用率，持续高于 70% 就说明 level 偏高，或gzip_types放得太宽
压缩级别每 +1，CPU 负担涨约 15%，但压缩率只升 2%–3%。从 level 6 到 9，体积几乎不降，耗时却翻倍，QPS 反而掉 23%。所以不是越高压缩越好，而是够用、稳用、不拖慢才是真平衡。
