静态资源二次压缩本质是前端预压缩与Nginx动态gzip同时启用导致的冗余处理；解决关键是禁用gzip on、仅启用gzip_static on，由Nginx直接返回同名.gz文件并自动设Content-Encoding头，实现分工明确、零重复压缩。
静态资源被二次压缩，本质是同一份文件在前端构建和 Nginx 层都做了 Gzip 压缩，导致 CPU 白耗、响应变慢，甚至个别情况下返回损坏内容。解决的关键不是“禁用压缩”，而是明确分工：前端负责预压缩，Nginx 负责识别并直接发送预压缩文件，跳过运行时压缩。
明确区分动态压缩与静态压缩路径
Nginx 默认的 gzip on 是动态压缩——每次请求都实时压缩响应体。而静态压缩指提前生成 .gz 文件（如 app.js.gz），由 Nginx 通过 gzip_static 模块直接返回。两者不能共存，否则可能对已压缩的 .gz 文件再压一次（虽然多数情况会失败或跳过，但逻辑混乱、浪费判断开销）。
- 关闭动态压缩：注释或删除
gzip on及所有gzip_*相关指令（如gzip_types、gzip_comp_level） - 启用静态压缩模块：确认 Nginx 编译时包含
--with-http_gzip_static_module（主流发行版默认已含） - 只保留一行核心配置：
gzip_static on;，放在server或location块中
确保前端构建输出 .gz 文件且命名规范
Nginx 的 gzip_static 只认同名 + .gz 后缀的文件。例如请求 /static/js/app.js，它会查找 /static/js/app.js.gz，存在则直接返回并自动加 Content-Encoding: gzip 头；不存在则回退返回原始 .js 文件（不压缩）。
- Webpack/Vite/Vue CLI 项目中，使用
compression-webpack-plugin（Webpack）或vite-plugin-compression（Vite），设置threshold: 1024（1KB）以上才压缩 - 关键配置项：
deleteOriginalAssets: false—— 必须保留原始文件，否则没回退路径 - 打包后检查输出目录：确认
index.html、main.css、chunk.js等均有对应.gz文件
验证行为与规避常见陷阱
配置生效后，需验证 Nginx 是否真的走静态路径，而非误触发动态压缩或返回未压缩内容。
- 用 curl 检查响应头：
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/static/js/app.js，应看到Content-Encoding: gzip且Content-Length接近 .gz 文件大小 - 禁止同时开启
gzip on和gzip_static on：二者逻辑冲突，Nginx 会优先尝试动态压缩，失去预压缩意义 - 不要手动给 .gz 文件加
Content-Encoding头：Nginx 自动添加，重复设置可能引发浏览器解析异常 - 注意文件权限：.gz 文件需与原始文件有相同读取权限，否则 Nginx 找到但无法打开，会静默回退到原文件
进阶：Brotli 静态支持（可选）
若想进一步提升压缩率（尤其文本类），可搭配 Brotli 预压缩。需额外编译 ngx_brotli 模块，并配置 brotli_static on;。此时需前端同时产出 .br 文件，Nginx 会根据客户端 Accept-Encoding 优先匹配 br > gzip > 无压缩。
- 浏览器兼容性良好（Chrome 52+、Firefox 44+、Edge 16+、Safari 11+）
- 无需关闭 gzip_static，Brotli 与 Gzip 静态路径互不干扰，Nginx 自动协商
- 建议仍保留 gzip_static 作为兜底，覆盖更老客户端
