启用gzip_static是降低Nginx CPU压力最有效方式：需构建时生成同名.gz文件并保留源文件，Nginx在静态资源location块中配置gzip_static on，与全局gzip on兜底协同，且须验证模块支持、文件存在性及响应头。
直接用预压缩的 .gz 文件响应请求，跳过实时压缩计算，是降低 Nginx CPU 压力最有效的方式之一。关键不在“开不开 gzip”，而在于构建阶段产出 .gz 文件 + Nginx 正确启用 gzip_static。
确认 Nginx 支持 gzip_static 模块
该功能依赖独立模块 http_gzip_static_module，不是基础 gzip 模块的子集。执行以下命令验证：
nginx -V 2>&1 | grep -o with-http_gzip_static_module
有输出才说明已编译支持。若无结果，需重新编译 Nginx 并添加 --with-http_gzip_static_module 参数。
构建阶段生成同名 .gz 文件
静态资源（JS、CSS、HTML、SVG 等）必须在打包时就产出对应 .gz 版本，不能等请求来了再压。
-
Webpack 项目：使用
compression-webpack-plugin，配置algorithm: 'gzip'和deleteOriginalAssets: false（原始文件必须保留） -
Vite 项目：引入
vite-plugin-compression，设ext: '.gz'，并注意filter避免误压 HTML（部分环境会触发 403） -
已有部署补救：批量生成，例如
find /usr/share/nginx/html -type f \( -name "*.js" -o -name "*.css" -o -name "*.svg" \) -exec gzip -c9 {} \; -exec mv {}.gz {}\.gz \;
完成后建议同步时间戳：touch -r index.js index.js.gz，避免缓存行为不一致
Nginx 配置 gzip_static 的正确位置
gzip_static on 不是辅助项，而是静态资源服务的主路径，必须放在具体服务静态文件的 location 块内，而非全局 http 块。
- 只写
gzip_static on;，不要在同一location里重复写gzip on或调高gzip_comp_level - 无需配置
gzip_types——它对类型无限制，只要存在同名.gz就尝试返回 - 典型 React/Vue 部署示例：
location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; gzip_static on; } - 注意执行顺序：
gzip_static在try_files之前生效；若try_files先重写路径，可能导致.gz找不到
与 gzip on 协同兜底，不互相干扰
二者可以且推荐共存，但职责分明：
-
gzip_static处理已预压缩的静态资源，零 CPU 开销 -
gzip on作为兜底，处理动态内容、API 响应或漏掉的静态文件 -
gzip on应在http块全局开启一次，并配好：gzip_types text/html text/css application/javascript application/json text/xml application/xml（务必含text/html）gzip_min_length 1000gzip_vary off（避免 CDN 缓存分裂）
