启用gzip_static on是压降Nginx CPU最有效手段：构建阶段产出同名.gz文件并保留源文件，Nginx在静态资源location块中启用gzip_static on且显式gzip off，配合全局gzip on兜底动态内容，四者齐备可使CPU瞬降30%～60%。
前端构建：必须产出 .gz 文件，且保留原文件
秒杀流量洪峰前，不能依赖运行时压缩。所有静态资源（JS、CSS、HTML、JSON、SVG）必须在打包阶段生成同名 `.gz` 文件：
-
Webpack 项目：用
compression-webpack-plugin，关键设deleteOriginalAssets: false（否则 Nginx 找不到源文件，gzip_static不触发）；threshold: 10240（只压 ≥10KB 的文件，避免小文件越压越大） -
Vite 项目：配
vite-plugin-compression，algorithm: 'gzip'、ext: '.gz'、deleteOriginFile: false -
已上线补救：在部署目录批量生成，例如：
find /usr/share/nginx/html -type f \( -name "*.js" -o -name "*.css" -o -name "*.html" \) -exec gzip -c9 {} \; -exec mv {}.gz {}\.gz \;
再同步时间戳：touch -r main.js main.js.gz，防浏览器缓存错乱
Nginx 配置：精准落在静态服务 location 块内
不要写在 http 或 server 顶层，必须嵌入真实服务静态资源的 location 块中，例如 React/Vue SPA 的根路径：
- 典型配置（放在
location / { ... }内）：gzip_static on;gzip off;（显式关闭该 location 的动态压缩，防干扰） - 不写
gzip_types——它对gzip_static完全无效；只要请求路径下存在xxx.js.gz，Nginx 就尝试返回 - 注意执行顺序：
gzip_static在try_files之前生效；若try_files $uri $uri/ /index.html把请求重写到/index.html，而该路径无index.html.gz，就会回退失败
协同兜底：gzip_static 主力 + gzip 兜底，但职责分明
二者共存更稳，但分工要清晰：
- 全局
http块保留基础 gzip（用于 API、动态 HTML 等）：gzip on;gzip_min_length 1000;gzip_types text/plain text/css application/json application/javascript text/xml; - 静态资源 location 中禁用
gzip_vary on——它会加Vary: Accept-Encoding，导致 CDN 缓存分裂；gzip_static本身靠文件存在性区分编码，无需此头 - 不关全局
gzip，但静态路径内显式gzip off，确保零误触发
上线前三步验证：缺一不可
配了不等于生效，必须实测：
-
查磁盘：进 Nginx root 目录，确认
main.a1b2.js和main.a1b2.js.gz同时存在、同目录、权限可读 -
查响应头：用
curl -H "Accept-Encoding: gzip" -I https://yoursite/static/js/main.a1b2.js，应返回Content-Encoding: gzip且Content-Length接近 .gz 文件大小 -
查日志：看 Nginx error log，若出现
open() "/path/to/main.js.gz" failed (2: No such file)，说明构建漏了或路径错配
