启用 gzip_static 可使 Nginx 直接返回预压缩 .gz 文件，降低首包延迟 10%~20%、CPU 占用 30%~60%；需前端构建时生成同名 .gz 文件并保留源文件，Nginx 在静态资源 location 块中配置 gzip_static on，与全局 gzip 形成主备协同，上线前须验证响应头、错误日志及 CPU 负载。
秒杀前夕流量突增，网关首包响应时间（TTFB）升高，往往卡在静态资源的实时压缩环节。启用 gzip_static 能让 Nginx 直接用预生成的 .gz 文件响应，跳过 CPU 密集型压缩计算，实测可将 JS/CSS 类资源的首包延迟压低 10%~20%，CPU 占用下降 30%~60%。
前端构建：必须产出同名 .gz 文件并保留源文件
不能等请求来了再压，必须在打包阶段完成预压缩：
- Webpack 项目：用
compression-webpack-plugin，关键设algorithm: 'gzip'、deleteOriginalAssets: false（必须保留main.js和main.js.gz共存），threshold: 10240（仅压 ≥10KB 的文件，避免小文件得不偿失） - Vite 项目：用
vite-plugin-compression，配algorithm: 'gzip'、ext: '.gz'，同样保留原始文件 - 生成后执行
touch -r main.js main.js.gz同步修改时间——浏览器缓存依赖Last-Modified，时间不一致会导致缓存失效或 Nginx 拒绝使用 .gz - 检查输出目录：确保
/static/js/app.abc123.js和/static/js/app.abc123.js.gz同路径、同权限、同时间戳
Nginx 配置：精准落在静态资源 location 块内
gzip_static on 不是全局开关，必须嵌入真实服务静态文件的 location 中：
- 推荐写法（适配 SPA）：
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;
} - 不要在该 location 内写
gzip_types——对gzip_static完全无效；也不建议加gzip_vary on，它会引发 CDN 缓存分裂，而gzip_static本身已靠文件存在性区分编码 - 可在该 location 内显式关闭动态压缩：
gzip off;，防止误触发，逻辑更干净
兜底与协同：gzip_static 和 gzip 共存但分工明确
二者不是互斥，而是主备关系：
- 全局
http块中保持基础 gzip 开启：gzip on;、gzip_min_length 1000;、gzip_types text/plain ...;——这是 fallback，当 .gz 缺失时自动降级为动态压缩 - 不关
gzip on，也不依赖它扛主力；gzip_static是主路径，gzip是保底，缺一不可 - 确保 Nginx 工作用户（如
www-data）对所有.gz文件有读权限，否则日志会出现open() "/path/file.js.gz" failed (13: Permission denied)
上线前必须验证的三件事
只改配置不验证，等于没做：
-
查响应头：用
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/static/js/app.xxxx.js，确认返回含Content-Encoding: gzip，且Content-Length接近本地.gz文件大小（不是原始 JS 大小） -
扫错误日志：Nginx error log 中若出现
open() "/xxx/app.js.gz" failed (2: No such file)，说明构建漏了文件或路径不匹配，立即回溯构建产物 - 比对 CPU 负载：在模拟秒杀压测中对比开启前后，重点关注 Nginx worker 进程的 CPU 使用率，特别是大量 JS/CSS 请求并发时是否显著回落
