调优 gzip_comp_level 的核心目标是让 CPU 不白忙活：该压的有效压、不该压的彻底跳过、已压好的直接复用；推荐 4–6 级，其中 4 级适合 API 网关（压缩率约 60%，CPU 温和），5 级适配混合型网关，6 级为 Nginx 默认值（压缩率 60%–75%），7–9 级增益极小却致 CPU 翻 4–5 倍，且对 JPEG/PNG/MP4 等无效。
调优 gzip_comp_level 的核心目标，是让 CPU 不在压缩上“白忙活”——该压的压得有效，不该压的彻底跳过，已压好的直接复用。线上网关 CPU 核心空转，往往不是因为没开压缩，而是压了不该压的、反复压同一内容、或用过高阶别硬扛小文件。
选 4–6 级：避开高压缩陷阱，守住响应底线
级别 7–9 看似“更省带宽”，实则极易引发 CPU 空转：
- 对 JPEG、PNG、MP4、woff2、gzip 预压缩文件等完全无效，Nginx 仍会尝试读取、判断、调用 zlib，纯属空转
- 相比级别 6，压缩率仅多 3%–5%，但 CPU 时间可能翻 4–5 倍，高并发下线程卡在 deflate 循环中
- 若网关后接 CDN 或反向代理，高压缩易触发
gzip_vary缓存分裂，导致缓存命中率暴跌，请求反复回源再压
推荐按场景落点：
- API 网关（JSON/XML 主流）：gzip_comp_level 4，压缩率约 60%，CPU 温和，首字节延迟低
- 混合型网关（透传静态资源+聚合接口）：gzip_comp_level 5，兼顾 HTML/JS/CSS 收益与稳定性
- 终端直连型网关（如 BFF 层）：gzip_comp_level 6，Nginx 默认值，压缩率 60%–75%，适配多数文本类响应
只压真正能压的内容，禁用零收益类型
默认 gzip_types 若包含 image/*、video/*、application/pdf，等于主动给 CPU 安排无效劳动：
- 用
gzip_types text/plain text/css application/javascript application/json;明确收窄范围 - 移除
text/html？不建议——除非你用 SSR 且模板已预压缩；否则 HTML 是 gzip 最大受益体 - 若后端已返回
Content-Encoding: gzip（如某些 Java 网关或 Node.js 中间件），务必加gzip_proxied any;并确认不重复压缩
绕过小文件，跳过“负优化”操作
压缩一个 200 字节的 JSON 响应，CPU 花费可能比传输还久：
- 设
gzip_min_length 1024;（至少 1KB），过滤掉 tiny 响应（如{"code":0}、空数组、短提示） - 搭配
gzip_vary on;，防止浏览器或 CDN 因编码标识缺失而缓存错乱，间接减少无效重压 - 启用
gzip_static on;，若构建流程已产出.js.gz、.css.gz，Nginx 直接 304 或 200 返回，完全绕过实时压缩
动态内容不硬压，用缓存代替实时计算
网关常转发模板渲染页、聚合 API 结果，这类响应每次生成都重新压缩，是 CPU 空转重灾区：
- 在 Nginx 上游加一层缓存（如
proxy_cache），缓存已压缩后的完整响应体 - 配合
add_header ETag $upstream_http_etag;和add_header Last-Modified $upstream_http_last_modified;，让客户端复用压缩结果 - 对低频更新页面（如帮助中心、政策页），走预渲染 + 预压缩 + 静态托管路径，彻底卸载网关压缩压力
