nginx微服务网关中需按路径前缀精细化配置gzip：/api/禁用或设低级别（gzip off或level 2）以省cpu；/static/启用gzip_static on+expires 1y实现零开销预压缩；/admin/或/设gzip on、level 5、完整gzip_types及gzip_vary，确保html/js/css有效压缩。
在微服务网关场景中，Nginx 作为前置反向代理，需对不同路径前缀的请求实施差异化的 Gzip 压缩策略——比如 /api/ 接口降低压缩级别以节省 CPU，/static/ 或 /assets/ 路径启用静态压缩并强缓存，而 /admin/ 后台页面则保持中等压缩。这并非全局开关，而是基于 location 的细粒度控制。
用 location 块按路径前缀隔离压缩行为
核心是把 gzip 指令下沉到具体 location 中，覆盖 http 或 server 级别的默认设置。Nginx 会按最长前缀匹配规则选择最精确的 location 块，确保分流准确。
-
/api/ 路径禁用或轻量压缩：动态接口响应体小、生成频繁，高压缩比得不偿失。可设
gzip off;或gzip_comp_level 2; -
/static/ 或 /assets/ 路径启用 gzip_static + 强缓存：配合前端构建时生成 .gz 文件（如 Vite 的
vite-plugin-compression），开启gzip_static on;并加expires 1y;，让浏览器直接读取预压缩文件，零 CPU 开销 -
/admin/ 或根路径 / 启用中等压缩：HTML/CSS/JS 混合输出，设
gzip_comp_level 5;并确保gzip_types包含text/html application/css application/javascript
必须配齐的基础指令才能生效
仅写 gzip_comp_level 不起作用。每个 location 中若要独立启用压缩，需显式声明完整链路：
-
gzip on;—— 必须开启，否则该 location 下所有 gzip_* 指令被忽略 -
gzip_min_length 1024;—— 避免压缩极小响应（如空 JSON）反而增大体积 -
gzip_types text/html application/json text/css application/javascript;—— 动态接口返回的 JSON 必须显式列入，否则不压缩 -
gzip_vary on;—— 让 CDN 和浏览器知道响应可能被压缩，避免缓存错乱
区分静态压缩与动态压缩的触发逻辑
两者不互斥，但优先级和适用对象不同：
-
gzip_static on;只对磁盘上存在同名 .gz 文件的请求生效（如请求/js/app.js→ 查找/js/app.js.gz）。找不到且gzip on;已启用，才走实时压缩 -
gzip on;处理的是后端动态吐出的内容（如 Tomcat 返回的 JSON、Spring Boot 的 HTML 页面），无法预生成 .gz，必须实时压缩 - 关键点：静态资源路径（如 /static/）应同时配置 gzip_static 和 gzip，实现 fallback；API 路径（如 /api/）只需 gzip off 或低级别，避免干扰业务响应时间
验证是否按路径生效
别依赖浏览器 Network 面板（它自动解压显示），用 curl 直接看原始响应头：
- 检查 API 路径：
curl -H "Accept-Encoding: gzip" -I https://gw.example.com/api/v1/user→ 应无Content-Encoding: gzip - 检查静态路径：
curl -H "Accept-Encoding: gzip" -I https://gw.example.com/static/main.js→ 应有Content-Encoding: gzip且Content-Length显著减小 - 对比同一域名下不同路径的
Vary和Cache-Control响应头，确认缓存策略也已按 location 分离
