nginx动静分离中静态文件压缩需全局启用gzip并配合location精准匹配，仅对指定mime类型静态资源生效；推荐使用gzip_static模块直接服务预压缩的.gz文件以降低cpu开销。
在 Nginx 动静分离环境下，静态文件压缩不是靠 location 直接“开启压缩”，而是通过配合 gzip 模块与 location 的精准匹配，实现**只对特定静态资源启用高效压缩**。关键在于：压缩行为由全局或 server 级的 gzip 配置驱动，而 location 负责限定作用范围、排除干扰（如代理动态请求）、并支持预压缩文件（.gz）的直接服务。
明确 gzip 压缩生效的前提条件
静态压缩依赖 Nginx 编译时已启用 --with-http_gzip_module（默认多数发行版已包含）。需在 http 或 server 块中开启基础配置：
-
启用压缩：
gzip on; -
指定压缩 MIME 类型：
gzip_types text/css application/javascript image/svg+xml;（注意：默认不压缩图片二进制格式如image/jpeg，但可手动添加image/png等；实际更推荐用预压缩） -
设置最小响应体大小：
gzip_min_length 1024;（避免小文件压缩反而增大开销）
用 location 精确控制静态资源压缩范围
动静分离中，location 的核心作用是把静态请求（如 /static/、/images/、后缀匹配）和动态请求（如 /api/、/ 交由 proxy_pass）严格区隔。只有落在静态匹配规则内的请求，才会进入 gzip 流程：
-
后缀匹配静态资源：
location ~* \.(css|js|svg|json)$ { gzip on; }—— 此处gzip on可写，但更推荐统一在 server 级开启，此处仅做逻辑隔离 -
路径前缀匹配静态目录：
location /static/ { alias /data/web/static/; }—— 此类 location 自动继承上级 gzip 配置，只要响应 MIME 在gzip_types中即触发压缩 -
排除动态代理路径：
location /api/ { proxy_pass http://backend; }—— 确保该路径不走 gzip，避免压缩后端返回的动态 JSON 影响性能或协议兼容性
推荐方案：启用 gzip_static 实现零开销压缩
对于 CSS/JS 等文本类静态资源，运行时 gzip 压缩有 CPU 开销。最佳实践是提前生成 .gz 文件（如 app.js.gz），再让 Nginx 直接发送，无需实时压缩。这需要：
- 编译 Nginx 时加入
--with-http_gzip_static_module（可用nginx -V 2>&1 | grep gzip_static验证） - 在静态资源目录中，为每个
.js、.css文件生成同名.gz文件（如main.css+main.css.gz） - 在对应
location中启用：gzip_static on; - 示例：
location ~* \.(css|js)$ { root /var/www/assets; gzip_static on; expires 1y; }
注意 sendfile 与 gzip 的协同
若启用了 sendfile on（提升大文件传输效率），它会绕过用户态，导致运行时 gzip 失效。解决方案有两个：
- 对纯静态文本资源，优先使用
gzip_static on，它与sendfile完全兼容 - 若必须运行时压缩，且需 sendfile，则需关闭
sendfile，改用aio threads;+directio等替代方案（适用于大文件流式场景，非主流静态压缩需求）
