直接用预压缩的.gz文件响应请求是降低nginx cpu压力最有效的方式，需在构建阶段生成同名.gz文件并配置gzip_static on，二者协同实现零cpu压缩与动态兜底。
直接用预压缩的 .gz 文件响应请求，跳过实时压缩计算，是降低 Nginx CPU 压力最有效的方式之一。关键不在“开不开 gzip”，而在于构建阶段产出 .gz 文件 + Nginx 正确启用 gzip_static。
前端构建阶段：必须生成同名 .gz 文件
静态资源（JS、CSS、HTML、SVG 等）不能等请求来了再压缩，必须在打包时就产出对应 .gz 版本：
- Webpack 项目：引入
compression-webpack-plugin，配置algorithm: 'gzip'和deleteOriginalAssets: false（必须保留原始文件） - Vite 项目：使用
vite-plugin-compression，设algorithm: 'gzip'、ext: '.gz' - 纯脚本补救：对已部署目录批量处理，例如：
find /path/to/static -type f \( -name "*.js" -o -name "*.css" -o -name "*.html" \) -exec gzip -c9 {} \; -exec mv {}.gz {}\.gz \; - 关键细节：.gz 文件需与源文件同目录；建议同步修改时间（如
touch -r index.html index.html.gz），避免缓存行为不一致
Nginx 配置要点：精准启用 gzip_static
gzip_static on 不是辅助项，而是静态资源服务的主路径，应放在具体服务静态文件的 location 块内：
- 只写
gzip_static on;，不要在同一 location 里重复写gzip on或调高gzip_comp_level - 无需配置
gzip_types——gzip_static对类型无限制，只要存在同名 .gz 就尝试返回 - 确保
location路径能匹配真实资源，例如 React 应用常用：location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; }，gzip_static on就加在这里 - 注意执行顺序：
gzip_static在try_files之前生效；若try_files先重写路径，可能导致 .gz 找不到
协同与兜底：gzip_static 和 gzip 共存策略
二者可以且推荐共存，但职责分明：
-
gzip_static处理已预压缩的静态资源，零 CPU 开销 -
gzip on作为兜底，处理动态内容、API 响应或漏掉的静态文件 -
gzip应在http块全局开启一次，并配好gzip_types（务必包含text/html）、gzip_min_length 1000、gzip_vary off（避免干扰 CDN 缓存） - 禁用
gzip_vary on：即使用了 .gz 文件，开启它仍会加Vary: Accept-Encoding，导致 CDN 缓存分裂
验证是否真正生效
不能只看配置是否写上，要实测行为：
- 用
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/static/js/main.xxxx.js查看响应头是否有Content-Encoding: gzip且Content-Length明显变小 - 检查 Nginx 错误日志，若出现
open() "/path/to/file.js.gz" failed (2: No such file)，说明构建漏了 .gz 或路径不匹配 - 对比开启前后服务器 CPU 使用率（尤其高并发时 JS/CSS 请求密集期），下降明显即说明成功卸载了压缩负载
