nginx启用gzip_static on后，优先查找同名.gz文件直接返回，需同时满足：请求头含accept-encoding: gzip、.gz文件存在且可读、原始文件保留、所在location启用了gzip on。
当 Nginx 配置了 gzip_static on，它不会实时压缩响应体，而是主动查找同名的 .gz 文件——找到就直接返回，找不到才退回到常规 gzip 压缩流程。这个逻辑看似简单，但能否生效，取决于构建、路径、配置三者是否严丝合缝。
自动查找规则：严格匹配 + 同级存在
Nginx 在收到一个请求（如 /static/js/app.abc123.js）后，会按固定顺序尝试打开以下路径（以该 URI 为基准）：
-
/path/to/app.abc123.js.gz（原始路径 +.gz后缀） - 不尝试
.gzip、.zst等其他后缀 - 不递归向上查找父目录中的
.gz文件 - 要求
.gz文件与源文件在同一目录、权限可读、且时间戳不早于源文件（否则可能被跳过）
优先分发条件：四者同时满足才启用
即使写了 gzip_static on，Nginx 也不会贸然用 .gz 文件，必须全部满足以下前提：
- 请求头包含
Accept-Encoding: gzip - 对应
.gz文件真实存在且可读 - 原始文件（如
app.js）依然保留在磁盘上（不能被插件删掉） - 当前 location 块中启用了
gzip on（作为兜底，缺.gz时能自动降级）
不依赖 MIME 类型判断
不同于常规 gzip_types 的白名单机制，gzip_static 的查找行为是路径驱动的，和响应的 Content-Type 无关。只要请求的 URI 对应一个磁盘上的文件，Nginx 就会尝试找它的 .gz 版本——哪怕它是 image/svg+xml 或 application/wasm，只要构建时生成了 .svg.gz 或 .wasm.gz，且配置正确，就能被命中。
如何确认它真正在工作
光看配置没用，得验证行为：
- 用
curl -H "Accept-Encoding: gzip" -I /static/js/app.js查响应头：应含Content-Encoding: gzip和明显变小的Content-Length - 检查 Nginx error log：若反复出现
open() "/xxx/app.js.gz" failed (2: No such file)，说明构建漏了或路径不对 - 对比 CPU 使用率：在大量 JS/CSS 请求涌入时，开启前后 worker 进程的 CPU 占用应有明显下降
