核心思路是只对文本类资源启用压缩，排除已压缩的二进制文件；设最小阈值1000字节避免小文件负优化；采用gzip_comp_level 6兼顾压缩率与cpu开销；配合gzip_static预压缩和gzip_vary确保缓存兼容性。
核心思路是：只对能显著压缩的资源启用、设合理阈值避免小文件负优化、用中等压缩级别兼顾效果与开销、配合预压缩降低实时计算压力。
选对压缩对象，避开无效场景
文本类资源压缩收益高、成本低；已压缩内容反而浪费CPU。实际配置中应明确限定类型，并排除常见陷阱：
- 必须包含：text/plain text/css application/javascript application/json text/xml application/xml
- 建议排除：image/.* font/.* video/.* application/pdf（这些基本不压缩或越压越大）
- 注意默认不压缩 text/html，需显式加入或依赖隐式支持（不同Nginx版本行为略有差异）
设好最小长度，防止小文件反向膨胀
小于1KB的HTML或JS片段经Gzip压缩后可能体积增加，尤其在低级别压缩时更明显。推荐值不是“越小越好”：
- gzip_min_length 1000 是较稳妥起点（1KB），覆盖绝大多数有效文本资源
- 低于512字节的响应基本不值得压缩，可直接跳过
- 不要设为0——那会强制压缩空响应、极短重定向头等，徒增CPU负担
用6级压缩，拒绝盲目追求极致
实测表明，从级别6升到9，压缩率仅提升约3%~5%，但CPU耗时翻4倍以上。生产环境应优先稳定而非理论最优：
- gzip_comp_level 6 是多数高流量站点的默认选择
- 若CPU长期高于70%，可降为5；若带宽成本极高且服务器冗余充足，再谨慎试7
- 级别1虽快，但压缩率常低于50%，浪费带宽；级别9几乎只适合离线预处理
启用 gzip_static 和 Vary 头，兼顾缓存与兼容性
静态文件预压缩 + 正确响应头，能减少重复计算并避免CDN或代理缓存混乱：
-
gzip_static on：提前生成
.gz文件（如app.js.gz），Nginx直接返回，零CPU开销 -
gzip_vary on：自动加
Vary: Accept-Encoding，确保CDN/反向代理正确区分压缩与未压缩版本 - 搭配 gzip_disable "msie6" 可规避旧IE解压异常，现代站点可考虑移除（IE6早已淘汰）
