Nginx静态压缩（gzip_static on）优先返回预生成.gz文件，动态压缩（gzip on）作为兜底；需前端构建时产出.gz文件，并配置gzip_min_length 1024、gzip_comp_level 6、gzip_types等参数平衡性能与压缩率。
直接在 Nginx 层启用 Gzip 压缩，配合前端构建时生成预压缩文件（.gz），是提升打包产物传输效率最有效的方式。核心不是“只开压缩”，而是“动静结合”——动态压缩兜底 + 静态 .gz 文件优先服务，减少 CPU 开销、加快响应。
确保前端构建输出 .gz 文件
Webpack/Vite/ESBuild 等工具支持在打包时自动生成 .gz 副本（如 app.js → app.js.gz）。这是关键前提：
- Vite：启用
build.rollupOptions.output.manualChunks后，配合插件如vite-plugin-compression，可自动产出 .gz 和 .br 文件 - Webpack：使用
compression-webpack-plugin，配置test: /\.(js|css|html|svg)$/i，生成对应压缩文件 - 产出后检查 dist 目录：应同时存在
index.html和index.html.gz、chunk.js和chunk.js.gz等
Nginx 启用 gzip_static 优先服务 .gz 文件
比运行时动态压缩更高效的方式是让 Nginx 直接返回已存在的 .gz 文件。需启用 gzip_static 指令（它优先级高于 gzip on）：
- 在
server或location块中添加：gzip_static on; - 确保前端资源路径可被匹配（例如
location /static/ { ... }或根 location） - Nginx 会自动查找同名 .gz 文件（如请求
/js/app.js，且存在/js/app.js.gz，则直接返回该文件并设置Content-Encoding: gzip） - 注意：
gzip_static不依赖gzip_types，但要求文件权限可读、MIME 类型能被正确识别
合理配置动态 gzip 作为兜底
当某些资源没生成 .gz 文件，或请求头不匹配时，仍需动态压缩保障兼容性。推荐以下平衡配置：
立即学习“前端免费学习笔记（深入）”；
-
gzip on;—— 必须开启 -
gzip_min_length 1024;—— 小于 1KB 的文件不压缩（避免负优化） -
gzip_comp_level 6;—— 6 级在压缩率（约 65%）与 CPU 占用间较均衡 -
gzip_types text/plain text/css application/javascript application/json text/javascript application/xml image/svg+xml;—— 显式声明，避免遗漏 SVG、JSON 等现代资源；无需包含text/html（默认始终压缩） -
gzip_vary on;—— 让 CDN 或代理缓存区分压缩/未压缩版本
验证是否真正生效
不能只看配置是否写对，要验证实际响应行为：
- 用 Chrome DevTools → Network 标签页，选中一个 JS/CSS 文件，查看 Response Headers 中是否有
Content-Encoding: gzip - 对比大小：Response 标签下 “Size” 是传输体积，“Content” 是解压后体积，两者差值越大说明压缩越有效
- 命令行验证：
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/app.js，检查返回头是否含Content-Encoding: gzip和Vary: Accept-Encoding - 若启用了
gzip_static，还可临时删掉某个 .gz 文件再测试，观察是否退回到动态压缩（确认兜底逻辑正常）
