推荐 gzip_comp_level 设为4–6级，其中api网关默认用5级；仅压缩text/css、application/json等可压缩类型，排除image/、video/等已压缩格式；设gzip_min_length 1000跳过小响应；启用gzip_static优先返回预压缩文件。

调优 gzip_comp_level 的核心目标，是让压缩真正“有用”——不压不该压的，不压已经压过的，更不为几KB流量把CPU拖进高延迟陷阱。线上网关最怕的不是带宽贵，而是计算时延突然抖动、请求排队、TTFB飙升。这往往就源于 gzip 配置失当。

选4–6级，别碰7–9

级别7到9带来的压缩增益极小（比级别6仅多压3%–5%），但单请求压缩耗时可能翻4–5倍。网关处理的是实时请求，每个压缩动作都是串行阻塞的，高并发下极易形成CPU热点，导致后续请求排队等待。实测在2核4G边缘网关上，级别4已能压掉约60%的JSON/JS/CSS体积，CPU增幅不到8%；级别5（推荐新API网关默认）压缩率约68%，延迟与带宽节省更均衡。

• 内网API或低延迟敏感服务：用 gzip_comp_level 4
• 面向公网的RESTful网关（如跨境API）：用 5，兼顾TTFB和传输量
• CPU余量充足、纯静态资源分发场景：可试 6，但需配合缓存策略

只压真正能压缩的内容

对 JPEG、PNG、MP4、WOFF2、GZ文件等本身已压缩的资源再启用gzip，不仅无效，还会白占CPU周期。Nginx不会智能识别文件是否已压缩，它只认MIME类型和字节流。

• 必须显式限定：gzip_types application/json text/plain text/css application/javascript text/javascript
• 务必排除：image/*、video/*、application/font-woff2、application/pdf 等零收益类型
• 若后端（如Spring Boot、Node.js中间件）已开启响应压缩并返回 Content-Encoding: gzip，Nginx默认跳过二次压缩——但若配置了 gzip_vary on 却没关后端压缩，反而会造成缓存分裂和误判

过滤小响应，避免空转

压缩一个128字节的空JSON {} 或200字节的错误提示，CPU花的时间可能比传输还长，纯属空转。

• 设 gzip_min_length 1000（即1KB），跳过微小响应
• 对API网关尤其关键：多数健康检查、OPTIONS预检、短错误体都低于此阈值
• 注意：CDN或客户端缓存若依赖 Vary: Accept-Encoding，过低的 min_length 会制造大量“压缩/未压缩”双版本缓存，降低命中率

用 gzip_static 替代实时压缩

对于构建时确定、长期不变的前端资源（如打包后的 app.js、style.css），与其每次请求都现场压缩，不如在构建阶段生成 .js.gz 和 .css.gz，再由Nginx直接返回。

• 开启 gzip_static on，Nginx会优先查找同名 .gz 文件
• 省去CPU压缩开销，响应更快更稳定
• 需确保构建工具（如Webpack、Vite）配置了 gzip 插件，并将 .gz 文件与源文件一同部署