启用 gzip_static 是降低 Nginx CPU 负载最有效方式：构建时生成同名 .gz 文件，Nginx 在 location 块中精准配置 gzip_static on，并与 gzip 共存但职责分离，上线前需验证磁盘文件、响应头和错误日志。
直接用预压缩的 .gz 文件响应请求，跳过实时压缩计算，是降低 Nginx CPU 负载最有效的方式。核心不在“开不开 gzip”，而在于构建阶段产出 .gz 文件 + Nginx 正确启用 gzip_static。
前端构建阶段：必须生成同名 .gz 文件
静态资源（JS、CSS、HTML、SVG、JSON 等）不能等请求来了再压缩，必须在打包时就产出对应 .gz 版本：
-
Webpack 项目：引入
compression-webpack-plugin，关键配置为algorithm: 'gzip'、deleteOriginalAssets: false（必须保留原始文件），建议threshold: 10240（仅压缩 ≥10KB 的文件） -
Vite 项目：使用
vite-plugin-compression，设algorithm: 'gzip'、ext: '.gz'，同样保留源文件 -
补救方案（已上线站点）：对静态目录批量生成，例如：
find /usr/share/nginx/html -type f \( -name "*.js" -o -name "*.css" -o -name "*.json" \) -exec gzip -c9 {} \; -exec mv {}.gz {}\.gz \; -
关键细节：.gz 文件需与源文件同目录；用
touch -r main.js main.js.gz同步修改时间，避免缓存行为不一致
Nginx 配置：精准启用 gzip_static 并匹配路径
gzip_static on 不是辅助项，而是静态资源服务的主路径，必须落在具体服务静态文件的 location 块内：
- 不要写在
http或server块顶层，应限定在真实资源路径下，例如：location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; }
把gzip_static on;加在这里 - 也可用正则精确匹配后缀：
location ~* \.(js|css|json|svg|woff2?|ttf|eot)$ { gzip_static on; } - 无需配置
gzip_types——gzip_static对类型无限制，只要存在同名 .gz 就尝试返回 - 注意执行顺序：
gzip_static在try_files之前触发；若try_files把请求重写到不存在 .gz 的路径（如 /index.html），会导致回退
协同兜底：gzip_static 与 gzip 共存但职责分明
二者推荐共存，但分工清晰，避免互相干扰：
- 全局
http块中开启基础 gzip：gzip on;gzip_min_length 1000;gzip_types text/plain text/css application/json application/javascript text/xml application/xml; - 静态资源
location中可显式关闭动态压缩：gzip off;（防止误触发，更干净） - 不建议开
gzip_vary on：它会加Vary: Accept-Encoding，导致 CDN 缓存分裂；gzip_static本身已通过文件存在性区分编码，无需此头 - 确认 Nginx 编译时含
--with-http_gzip_static_module，否则指令无效
上线前验证：三步确认是否真正生效
不能只看配置写了没，要实测行为：
-
查磁盘：确认目标路径下同时存在
app.js和app.js.gz，且大小合理（如 120KB → 35KB） -
查响应：用
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/js/app.js，应看到：Content-Encoding: gzipContent-Length: 35678（接近本地 .gz 文件大小）ETag值应基于 .gz 文件的 inode + mtime 生成 -
查日志：若出现
open() "/path/to/app.js.gz" failed (2: No such file)，说明构建漏了或路径不匹配
