最稳妥方式是在Nginx的http块中全局启用gzip，需配置gzip on、gzip_min_length 1024、gzip_comp_level 6、精准的gzip_types（如text/css、application/json等）、gzip_vary on及gzip_proxied any，并通过curl验证Content-Encoding: gzip生效。
直接在 Nginx 的 http 块 中配置一组完整参数，才能真正开启有效的文本传输压缩。只写 gzip on; 是无效的——它只是开关，不设类型、不控阈值、不验响应，等于没开。
必须放在 http 块里全局启用
不要塞进 server 或 location 里，否则容易遗漏接口或被覆盖。正确做法是编辑 /etc/nginx/nginx.conf，在 http { 开头后、include 语句前插入配置：
gzip on;-
gzip_vary on;—— 让 CDN 和代理知道要按编码方式缓存 -
gzip_proxied any;—— 确保反向代理来的请求也能压缩 -
gzip_http_version 1.1;—— 明确要求 HTTP/1.1 及以上才启用
精准指定哪些内容要压缩
默认只压 text/html，JS、CSS、JSON、SVG、WASM 等全都不会动。必须手动加进 gzip_types：
- 推荐清单：
text/plain text/css application/javascript application/json application/xml text/xml application/rss+xml image/svg+xml font/ttf font/otf application/wasm application/ld+json - 别加图片：
image/jpeg、image/png这类本身已压缩，再 gzip 可能变大，还白耗 CPU - 注意大小写和斜杠格式：Nginx 对 MIME 类型区分严格，写错就失效
设好压缩门槛和强度
太小的响应压了反而更慢，太高的级别让 TTFB 延迟明显。生产环境建议：
-
gzip_min_length 1024;—— 跳过 1KB 以下的响应（如空 JSON、短提示） -
gzip_comp_level 6;—— 级别 6 是当前压缩率与 CPU 开销的最佳平衡点；9 级只比 6 级省 3%~5% 体积，但首屏延迟多出 10ms 左右 -
gzip_buffers 16k 8k;—— 避免频繁分配内存，提升吞吐稳定性
验证是否真生效
配完 reload 后，用 curl 测试关键资源：
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/app.js- 看响应头里有没有
Content-Encoding: gzip - 再对比未带
Accept-Encoding头的请求，确认体积明显下降
