启用Nginx Gzip压缩的关键是精准控制：仅对text/plain、text/css、application/javascript等文本类资源启用，排除图片/视频/字体等二进制格式；压缩级别设为5以平衡效果与CPU开销；设置gzip_min_length 1024避免小文件越压越大；必须开启gzip_vary on并优先使用gzip_static on预压缩。
在静态资源分发中启用 Nginx 的 gzip 压缩，关键不是“开了就行”，而是让压缩真正生效、不拖慢服务、也不白耗 CPU。核心在于精准控制作用对象、压缩强度和执行方式。
只对可压缩的文本类资源启用
gzip 对已经高压缩的二进制格式（如 PNG、JPEG、WebP、MP4、WOFF2、PDF）几乎无效，强行压缩反而浪费 CPU，还可能因体积增大导致“越压越大”。应明确限定作用范围：
- 必须包含：text/plain、text/css、application/javascript、application/json、application/xml+rss、image/svg+xml
- 推荐排除：image/.*、application/pdf、video/.*、font/.*（尤其 WOFF2 不建议再压）
- 避免遗漏：若用 Web API 返回 XML 或纯文本，需手动补全对应 MIME 类型
压缩级别设为 5，兼顾效果与开销
gzip_comp_level 并非越高越好。实测表明：
- 级别 4：压缩率约 60%，适合高并发、CPU 紧张的网关层
- 级别 5：压缩率约 68%，响应延迟与 CPU 占用平衡性最佳，新站点默认推荐
- 级别 6：达 75%，但 CPU 消耗明显上升，仅当带宽严重受限且服务器负载长期低于 30% 时考虑
- 7–9 级：压缩率提升不足 5%，worker 进程 CPU 使用率却常翻倍，应禁用
防止小文件反向增重
小于 1KB 的 HTML、JS 或 CSS 片段，经 gzip 压缩后可能因压缩头开销反而变大。通过 gzip_min_length 1024 可规避该问题。这个值不是固定死的，可根据实际资源分布微调：
- 若站点大量使用内联小脚本或微组件，可设为 512，但需配合测试确认无体积增长
- 若主要分发构建后的 bundle 文件（通常 >10KB），保持 1024 即可
- 务必搭配 gzip_vary on，确保 CDN 和代理能正确缓存不同编码版本
优先用预压缩，绕过实时 CPU 计算
前端构建工具（如 Vite、Webpack）配合 compression 插件可生成 .gz 文件。启用 gzip_static on 后，Nginx 会自动查找并返回 app.js.gz 而非实时压缩 app.js：
- 需确保 .gz 文件与源文件时间戳一致，否则部分 Nginx 版本会跳过使用；可用 touch -r app.js app.js.gz 同步
- 仍要保留 gzip on 作为兜底，防止预压缩文件缺失时降级失败
- 检查 Nginx 是否编译了 ngx_http_gzip_static_module，精简版可能未包含
