如何利用 gzip_static 与预压缩文件显著降低生产环境CPU压缩负担？

本文共计734个文字，预计阅读时间需要3分钟。

直接使用预压缩的+.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 消耗从请求高峰转移到构建阶段，零运行时压缩开销，对高流量静态站点效果立竿见影。