记录一下那天晚上的排查过程。一台 2 核 4G 的轻量服务器，nginx 加 gzip on 并调了 gzip_comp_level 6，接口返回的 JSON 有几十 K，开压缩后 QPS 从 1200 掉到 500，top 里 nginx 的 us 直接到 90%。
刚开始盯着「gzip_min_length 设成 0，几百字节的响应也被压，得不偿失」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。gzip_comp_level 每高一级 CPU 消耗成倍增加，6 级对动态 JSON 太重。少数情况下是每次请求都重新压缩，没开 gzip_static 也没做缓存。
不容易想到的是，gzip_types 把图片和字体也包了进去，本来就已经压过一轮。
量一下开压缩前后的 CPU 和 QPS
ab -n 2000 -c 100 http://127.0.0.1/api/list接着把压缩级别降到 2 到 4 之间
grep -nE 'gzip_comp_level|gzip_min_length|gzip_types' /etc/nginx/nginx.conf再往下改完检查配置并平滑重载
nginx -t && nginx -s reload静态资源改成预压缩文件
gzip -k -6 /www/wwwroot/site/static/app.js && ls -l /www/wwwroot/site/static/怎么算真的好了，看的是同一批现象。压测 QPS 回到 1000 以上，nginx 进程 CPU 降到 50% 左右，响应头里 Content-Encoding 仍然有 gzip。
这里还有个坑。压缩级别超过 4 收益很小，静态文件用 gzip_static 直接发 .gz 更省；HTTPS 场景下别对已经加密的二进制再做压缩。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。