开启 gzip 压缩的关键在于配置位置、作用范围和类型匹配：需将 gzip on 及相关参数置于 http 块顶层或同级 location 内，显式设置 gzip_types 包含 text/css、application/javascript、image/svg+xml 等 alias 所服务的可压缩类型，并配置 gzip_min_length ≥1024 避免小文件负优化，最后通过 curl 或浏览器验证 content-encoding: gzip 是否生效。
alias 配置静态资源时开启 Gzip 压缩，关键不是“能不能开”，而是“在哪开、开给谁、怎么开才不冲突”。alias 本身只是路径映射，不影响压缩逻辑；真正起作用的是 gzip 配置的位置和生效范围——必须确保它覆盖到 alias 所服务的请求路径，且类型匹配、大小合理。
gzip 必须放在能触达 alias location 的作用域里
alias 写在某个 location 块里，那 gzip 配置就得能影响到这个 location。最稳妥的方式是把 gzip on 和相关参数写在 http 块顶层，全局生效：
- 不要只写在 server 块里却漏掉该 location 的匹配范围
- 更不要只写在另一个不相关的 location 里（比如 /api）
- 如果只想为 alias 路径单独控制，可在同一 location 块内直接启用 gzip（Nginx 支持 location 级别配置）
gzip_types 要包含 alias 提供的文件类型
alias 通常服务图片、JS、CSS、SVG 等静态文件，但默认 gzip_types 只含 text/html。必须显式补全：
- text/css、application/javascript 对应 .css/.js
- image/svg+xml 对应 .svg（文本型矢量图，可压缩）
- 避免写 image/png 这类二进制类型——实际压缩效果极差，还白耗 CPU
- 常见安全组合：text/plain text/css application/javascript application/json image/svg+xml
配合 gzip_min_length 和缓冲区，避免小文件负优化
太小的文件压缩后反而变大，或压缩开销超过收益。alias 目录下常有 favicon.ico、small.png 等小资源：
- 设 gzip_min_length 1024（1KB），比默认 20 字节更合理
- 配 gzip_buffers 16 8k，避免高并发下缓冲不足
- 若 alias 主要服务大图（如 /img_store/），可关闭对 image/* 的压缩，专注文本类资源
验证是否真生效，别信配置写了就行
改完 reload 后，用真实请求验证，不能只看配置语法正确：
- curl -H "Accept-Encoding: gzip" -I http://localhost/xxx.js → 检查响应头是否有 Content-Encoding: gzip
- 浏览器 F12 → Network → 找对应资源 → 对比 “Size” 和 “Content” 列，压缩后 Content 应明显小于 Size
- 注意：如果用了 gzip_static on，需确保磁盘上存在 .gz 文件，否则会回退到动态压缩或不压
