启用 gzip_static 是降低 nginx cpu 压力最有效方式之一，需在构建阶段生成同名 .gz 文件并配置 location 块中开启 gzip_static on，优先返回预压缩文件，缺失时回落动态压缩。
直接用预压缩的 .gz 文件响应请求，跳过实时压缩计算，是降低 Nginx CPU 压力最有效的方式之一。核心在于构建阶段生成 .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+gzip -c9批量处理已部署的静态目录，例如对所有.js、.css、.html文件生成同名 .gz - 关键细节：.gz 文件需与源文件在同一目录，且修改时间建议同步（
touch -r index.html index.html.gz），避免缓存行为不一致
Nginx 配置：启用 gzip_static 并确保路径匹配
gzip_static 不是补充项，而是替代动态压缩的主路径，配置要落在具体服务静态资源的 location 块内：
- 必须开启：
gzip_static on;（注意不是gzip on，后者仅用于动态内容） - 无需配置
gzip_types—— gzip_static 对文件类型无限制，只要存在 .gz 就尝试返回 - location 要能覆盖到实际资源路径，比如 React 应用通常为
location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; }，gzip_static 就加在这里 - 优先级高于 gzip：如果 .gz 文件存在且客户端支持 Accept-Encoding: gzip，Nginx 直接发 .gz；缺失时才回落到 gzip 动态压缩（兜底保障）
验证与注意事项
上线前确认三件事，避免“配了却没生效”：
- 检查磁盘：目标目录下确实有
main.a1b2.js和main.a1b2.js.gz同时存在 - 检查响应头：用
curl -H "Accept-Encoding: gzip" -I http://yoursite/js/main.js，应看到Content-Encoding: gzip且Content-Length接近 .gz 文件大小 - 禁用 gzip 动态压缩（可选但推荐）：在该 location 中显式写
gzip off;，防止误触发；全局 gzip 可保留，只在静态资源路径关闭 - 模块依赖：确认 Nginx 编译时包含
--with-http_gzip_static_module，否则指令不识别
这套方案把 CPU 消耗从请求高峰转移到构建阶段，零运行时压缩开销，对高流量静态站点效果立竿见影。
