预压缩 .gz 文件响应请求是降低 Nginx CPU 压力最有效方式：构建阶段需产出同名 .gz 文件并同步时间戳，Nginx 在 location 块中启用 gzip_static on 且与 gzip on 兜底共存，curl 直连验证 Content-Encoding: gzip 及长度匹配。
直接用预压缩的 .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 块内，而非全局 http 块。
- 只写
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 缓存分裂
验证是否真正生效
别只看浏览器 Network 面板——它可能显示的是 CDN 返回的压缩头，而非 Nginx 本身。
- 用 curl 直连 Nginx（绕过 CDN）：
curl -H "Accept-Encoding: gzip" -I http://localhost/style.css - 命中静态压缩时，响应头应含
Content-Encoding: gzip，且Content-Length接近你本地运行zcat style.css.gz | wc -c的结果 - 如果返回原始大小，检查：.gz 文件是否存在且路径正确？客户端请求头是否含
Accept-Encoding: gzip？Nginx 是否重载了配置？
