gzip_static预压缩是降低Nginx CPU负载最有效方式：构建时生成同名.gz文件，location块中启用gzip_static on，与gzip共存但职责分离，需验证文件存在、响应头及日志。
“gzip惰性文件计算策略”并不是一个标准术语，实际想表达的是：**避免每次请求都实时压缩，改用预压缩（gzip_static）+ 按需兜底（gzip on）的协同机制，从而消除高并发下因重复压缩导致的 CPU 排队和响应延迟。**
核心思路：压缩不发生在请求时，而发生在构建或上线前
高频网页请求（如首页 HTML、商品列表 JSON、静态 JS/CSS）若每次都走实时 gzip，Nginx 会在每个连接中调用 zlib 做 LZ77+Huffman 编码——这会迅速吃满 CPU 核心，尤其在突发流量下形成算力排队。真正的解法是“把压缩工作从运行时搬到构建时或部署前”。
- 前端资源（JS/CSS/HTML/SVG/JSON）在打包阶段就生成
.gz文件，与源文件同目录存放 - Nginx 配置
gzip_static on，收到请求后直接返回已存在的.gz文件，零 CPU 开销 - 对动态内容（如后端渲染的 HTML、接口返回的 JSON）保留
gzip on作为兜底，但仅限必要类型和最小体积阈值
关键配置：让 gzip_static 真正生效的三要素
很多团队开了 gzip_static on 却没效果，问题往往出在路径、时机或文件状态上：
-
必须落在服务静态资源的 location 块内：比如
location /static/ { root /var/www; gzip_static on; }，不能只写在 http 块顶层 -
同名 .gz 文件必须存在且时间戳一致：用
touch -r main.js main.js.gz同步修改时间，否则浏览器可能因 ETag 或缓存逻辑拒绝使用 -
禁止与 try_files 冲突：如果
try_files $uri $uri/ /index.html;把请求重写到/index.html，而该路径下没有index.html.gz，就会跳过 gzip_static 直接回退到原始文件甚至触发动态压缩
动静分离：哪些该预压，哪些可动态压，哪些坚决不压
不是所有文件都适合进预压缩流水线，也不是所有响应都值得实时压——混用反而增加负担：
-
必预压：构建产出的 JS/CSS/HTML/JSON/SVG（≥10KB），用
compression-webpack-plugin或vite-plugin-compression生成，保留原文件 -
可动态压：后端返回的 JSON 接口（如
/api/report），设gzip_min_length 1024，只压 ≥1KB 的响应，避开几十字节的小返回 -
禁压：JPG/PNG/WebP/MP4/woff2 等本身高压缩格式，Nginx 默认不列入
gzip_types，强行加入只会白耗 CPU、体积不变
协同兜底：gzip_static 和 gzip 共存但各司其职
二者不是二选一，而是分工明确的组合：
- 全局 http 块开启基础 gzip：
gzip on; gzip_min_length 1000; gzip_types application/json text/css application/javascript; - 在静态资源 location 中显式关闭动态压缩：
gzip off;，确保绝不走实时路径 - 不启用
gzip_vary on：gzip_static 通过文件存在性判断是否返回压缩版，不需要靠 Vary 头触发 CDN 缓存分裂
