在 virtual host 的 server 块中配置 gzip 和 gzip_static 是兼顾灵活性与性能的最佳实践：动态压缩需设 gzip_types、min_length、level 和 vary；静态压缩依赖构建生成的 .gz 文件并配合 location 精确启用；辅以 sendfile、open_file_cache 和 read_ahead 等内核级优化提升传输效率。
直接在 Virtual Host（即 server 块）中配置静态资源压缩与预读取，是兼顾灵活性与性能的常用做法。它不依赖全局设置，可按站点差异化控制，同时避免影响其他服务。
启用 gzip 动态压缩（适用于无预构建 .gz 文件的场景）
把压缩配置放在 server 块内即可生效，无需写进 http 全局块——但注意：若 http 块已开启 gzip on，此处再开不会冲突，只是覆盖作用域更小。
-
必须指定压缩类型：只写
gzip on;不够，gzip_types至少要包含text/css application/javascript text/html，否则 JS/CSS 不会被压缩 -
设最小阈值防负优化：
gzip_min_length 1024;避免压缩极小文件（如 200 字节的 favicon.ico），反而增大体积 - 压缩等级选 5 或 6：4–6 是 CPU 开销与压缩率的合理平衡点；设为 9 会显著拖慢高并发响应
-
务必开启 Vary 头：
gzip_vary on;让 CDN 或代理知道该响应有压缩/未压缩两个版本，避免缓存错乱
启用 gzip_static 静态压缩（推荐生产环境使用）
如果前端构建时已生成 .js.gz、.css.gz 等文件（如用 Vite 插件 vite-plugin-compression 或 Webpack 的 compression-webpack-plugin），应在对应静态资源 location 中启用 gzip_static on。
-
优先级高于动态 gzip：Nginx 会先找同名
.gz文件，存在则直接返回，零 CPU 开销 -
只需一行启用：在
location ~* \.(js|css|json|svg)$ { ... }内加gzip_static on;即可 -
不要和 try_files 冲突：确保
gzip_static所在 location 的root路径下真实存在.gz文件，且权限可读 -
兼容旧客户端：可搭配
gunzip on;（需启用ngx_http_gunzip_module），对不支持Accept-Encoding: gzip的请求自动解压后返回原文件
配合文件系统级优化提升读取速度
压缩只是传输环节，真正提速还要靠更快地把文件送进网络栈。
-
开启零拷贝：
sendfile on;+tcp_nopush on;，跳过用户态内存拷贝，直接从磁盘 DMA 到 socket 缓冲区 -
缓存文件元数据：
open_file_cache max=1000 inactive=30s;+open_file_cache_valid 60s;，减少open()/stat()系统调用 -
预读大文件：
read_ahead 1m;（放在 location 或 server 块），对 >1MB 的 JS/CSS 提前加载后续块，降低延迟 -
避免 root/alias 混用导致路径错误：静态资源 location 推荐用
root+location /static/，而非alias，更易维护且不易出错
验证是否真正生效
不能只看响应头有没有 Content-Encoding: gzip，要交叉确认：
- 用
curl -I -H "Accept-Encoding: gzip" https://yoursite.com/app.js查看是否返回200且含Content-Encoding: gzip - 对比响应
Content-Length和原始文件大小，缩小 60%~80% 才算有效压缩 - 浏览器 Network 面板中检查该资源的
Vary: Accept-Encoding是否存在 - 若启用了
gzip_static，可临时删掉.gz文件，观察是否退回到动态压缩或 404，来反向验证逻辑
