启用 gzip_static 是服务静态资源最省 CPU、响应最快的方案，它与 gzip on 职责分离：前者直接返回预压缩的 .gz 文件，后者仅兜底动态或漏压内容。
直接用 gzip_static 读取预压缩的 .gz 文件，是服务静态资源最省 CPU、响应最快的方案。它和运行时 gzip on 不是“一起开更厉害”，而是要明确分工：前者负责已打包好的 JS/CSS/HTML 等文件，后者只兜底动态内容或漏掉的资源。
构建阶段必须产出 .gz 文件
Webpack、Vite 或其他构建工具需在发布时同步生成 .gz 版本，并保留原始文件：
- Webpack：用
compression-webpack-plugin，设deleteOriginalAssets: false - Vite：用
vite-plugin-compression，指定algorithm: 'gzip'和ext: '.gz' - 手动补救：对已部署目录批量执行
find /path -name "*.js" -exec gzip -c9 {} \; -exec mv {}.gz {}\.gz \; - 关键细节：.gz 文件必须与源文件同目录、同名；建议用
touch -r app.js app.js.gz同步时间戳，避免缓存异常
nginx 配置只在 location 块中启用 gzip_static
gzip_static on 必须放在具体服务静态文件的 location 块里，不能写在 http 或 server 顶层：
- 例如 React/Vue 应用常用路径：
location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; gzip_static on; } - 不要在同一 location 写
gzip on，否则会干扰判断逻辑，失去预压缩意义 -
gzip_types对gzip_static完全无效——它只看文件是否存在，不校验 MIME 类型 - 确保
try_files不提前重写路径，否则可能让 Nginx 找不到同名 .gz 文件
gzip_static 和 gzip on 可共存，但职责分离
推荐两者都启用，但必须分层配置：
- 在
http块全局开启gzip on，配好gzip_types（含text/html）、gzip_min_length 1000、gzip_vary off（避免 CDN 缓存分裂） - 这个
gzip on只用于 API 响应、动态 HTML、未预压缩的小文件等兜底场景 -
gzip_static on在 location 中接管所有匹配的静态资源请求，零 CPU 开销返回 .gz 文件 - 禁用
gzip_vary on：即使用了 .gz 文件，开启它仍会加Vary: Accept-Encoding，导致 CDN 多份缓存
验证是否走对路径
别只看响应头有没有 Content-Encoding: gzip，要确认它来自预压缩文件而非运行时压缩：
- 用
curl -H "Accept-Encoding: gzip" -I /static/js/app.js，检查Content-Length是否接近本地app.js.gz的大小 - 临时删掉
app.js.gz，再请求同一地址，应返回未压缩的app.js且无Content-Encoding头 - 确保 .gz 文件权限和原始文件一致，否则 Nginx 会静默回退到原文件
