gzip_comp_level合理取值为1–9，但推荐4–6级：1–3级适合高并发低cpu场景，4–6级兼顾压缩率与性能（5级最稳妥），7–9级cpu开销剧增而收益甚微；需配合gzip on、min_length、types、vary等指令及静态预压缩协同生效。
Nginx 本身不支持“按文件大小或访问频率动态调整压缩级别”，所谓“压缩级别配置”，本质是通过 location 分块 + 类型匹配 + 基础参数协同 实现的静态分层控制。关键不是调一个数字，而是让不同资源走最合适的压缩路径。
明确 gzip_comp_level 的合理取值范围
该参数取值为 1–9，但并非越高越好：
- 1–3 级：适合高并发、CPU 敏感场景，压缩快、开销低，文本资源体积通常减少 40%–60%
- 4–6 级：推荐默认区间，平衡压缩率与性能；gzip_comp_level 5 是多数生产环境最稳妥的选择
- 7–9 级：CPU 开销显著上升，压缩率提升微弱（仅多压 5%–10%），一般无需启用
按资源类型关闭或分级压缩
已压缩格式必须禁用 gzip，避免白耗 CPU；文本类资源才值得压缩：
- CSS/JS/HTML/JSON/SVG/XML 等文本资源：统一设
gzip_comp_level 5或6 - JPG/PNG/WebP/GIF/woff2/mp4 等二进制资源：在对应 location 中显式写
gzip off - 示例配置：
location ~* \.(jpg|jpeg|png|webp|gif|woff2|mp4|avi)$ {<br> gzip off;<br>}
按路径精细化控制压缩强度
前端资源、API 接口、后台页面对延迟和带宽诉求不同，应分开配置：
-
location ^~ /static/或/assets/：启用中等压缩，如gzip_comp_level 5 -
location ^~ /api/：建议设gzip_comp_level 3或直接gzip off，减少后端响应延迟 -
location /（主页面）：可设gzip_comp_level 6，兼顾首屏 HTML 加载体验
必须配套的基础指令才能生效
单独改 gzip_comp_level 没用，以下参数缺一不可：
-
gzip on;：全局或局部开启开关，缺省即不压缩 -
gzip_min_length 1024;：小于 1KB 的响应不压缩，防止越压越大 -
gzip_types text/html application/json text/css application/javascript image/svg+xml;：动态内容（如 PHP/Node 输出的 JSON）也需明确列入 -
gzip_vary on;：确保 CDN 或代理能区分压缩/未压缩版本，避免缓存污染
更优解：用预压缩替代动态压缩
构建时生成 .js.gz、.css.gz 等文件，Nginx 启用 gzip_static on 直接返回，零 CPU 开销、压缩率更高：
- Vite 项目用
vite-plugin-compression，Webpack 项目用compression-webpack-plugin - Nginx 配置只在静态 location 块内加
gzip_static on;，不要放在 http 或 server 顶层 - .gz 文件须与源文件同目录、修改时间一致（
touch -r app.js app.js.gz），否则会退化为动态压缩
