gzip_comp_level推荐设为5或6：5级压缩率约68%、cpu温和、适合低延迟服务和ssr页面；6级为nginx默认值、压缩率约75%、适合常规静态站点；7–9级增益不足5%但cpu翻4倍以上，应避免滥用。
gzip_comp_level 设为 5 或 6 最符合性能最优。
推荐值：5 是低延迟服务的首选
级别 5 压缩率约 68%，CPU 占用温和，响应延迟可控。特别适合 SSR 页面、JSON 接口、首屏加载敏感的 Web 应用。它在压缩收益和处理耗时之间取得明显优势，实测比级别 6 平均减少约 12% 的 CPU 时间，而体积仅多出不到 7%。
- 适用场景：面向用户的主站、API 服务、实时性要求高的接口
- 配置示例：gzip_comp_level 5;
- 验证方式：用 curl -H "Accept-Encoding: gzip" -I http://your-site/xxx.js 检查 Content-Encoding: gzip 和响应头大小
默认值 6 适合常规静态站点
级别 6 是 Nginx 官方默认值，压缩率约 75%，对 HTML/CSS/JS 等文本类资源效果稳定。适用于带宽成本较高、服务器 CPU 余量充足、且无强延迟约束的典型网站。
- 适用场景：企业官网、CMS 类站点、CDN 回源压力较大的部署
- 注意：若后端已由应用或 CDN 提前压缩（如 Spring Boot 启用 gzip、Cloudflare 自动压缩），再设为 6 可能造成重复压缩，徒增 CPU 开销
避开 7–9 级——增益小、代价大
从级别 6 到 9，压缩率提升通常不足 5%，但 CPU 时间可能翻 4 倍以上，高并发下易引发响应延迟抖动甚至超时。对 JPEG/PNG/MP4/.gz 等已压缩资源完全无效，还可能因小文件反复压缩得不偿失。
- 级别 7 起就明显偏离性价比曲线，除非你有明确监控证据表明带宽是唯一瓶颈，且服务器长期 CPU 使用率低于 10%
- 避免在容器化环境、边缘节点或 ARM 小型实例中启用高压缩等级
配合关键配置才真正生效
单调 gzip_comp_level 不足以发挥效果，需同步优化其他参数：
- gzip_types：至少包含 text/plain text/css application/json application/javascript，禁用图片、字体、视频等无效类型
- gzip_min_length：设为 1000（1KB），跳过极小响应体，省去无谓开销
- gzip_vary on：确保缓存系统（如 CDN）能正确区分压缩与非压缩版本
- gzip_proxied any：当 Nginx 作反向代理时，保证上游返回内容也能被压缩
