Nginx 预压缩需构建阶段生成同名 .gz 文件并同步时间戳，Nginx 在静态 location 中启用 gzip_static on 优先返回，无需动态压缩；验证需比对 Content-Length、ETag 和 Last-Modified。

要让 Nginx 直接返回预压缩的 .gz 文件、跳过实时压缩计算，从而显著缩短 TTFB（尤其是首字节时间），核心不是“开 gzip”，而是构建阶段产出文件 + Nginx 精准启用 gzip_static。它不走动态压缩路径，无 CPU 开销，响应更快更稳定。

构建阶段：必须生成同名 .gz 文件并同步时间戳

静态资源（JS/CSS/HTML/SVG 等）在打包时就要输出对应的 .gz 版本，不能靠 Nginx 临时生成。

• Webpack：用 compression-webpack-plugin，设 algorithm: 'gzip' 和 deleteOriginalAssets: false（原始文件必须保留）
• Vite：引入 vite-plugin-compression，配置 algorithm: 'gzip'、ext: '.gz'
• 补救脚本（已部署环境）：find /path/to/static -type f \( -name "*.js" -o -name "*.css" -o -name "*.html" \) -exec gzip -c9 {} \; -exec mv {}.gz {}\.gz \;
• 关键细节：.gz 文件必须与源文件同目录；建议执行 touch -r index.html index.html.gz 同步修改时间，避免缓存行为异常

Nginx 配置：只在静态资源 location 块中启用 gzip_static

gzip_static on 不是全局开关，也不受 gzip_types 控制——它只在匹配到真实磁盘路径的 location 内生效，且优先级高于 try_files。

• 推荐正则匹配后缀：location ~* \.(js|css|json|svg|woff2?|ttf|eot)$
• 该 location 内必须有 root 或 alias，确保 Nginx 能按请求路径拼出 /xxx.js.gz 的磁盘路径
• 不要写在 http 或 server 块顶层；不要和 try_files $uri 混用——若 $uri 指向的是无 .gz 的路径，会跳过 gzip_static
• 无需重复写 gzip on 或 gzip_comp_level，这些属于兜底动态压缩，与 gzip_static 分工明确

验证是否真正生效：别只看响应头

仅凭 Content-Encoding: gzip 无法区分是预压缩还是动态压缩。需交叉验证：

• 用 curl -I -H "Accept-Encoding: gzip" https://yoursite.com/static/app.js 获取响应头
• 检查 Content-Length 是否等于本地 app.js.gz 文件大小（ls -l app.js.gz）
• 查看响应头中 ETag 是否由 .gz 文件的 inode + mtime 组成（原始文件的 ETag 格式不同）
• 对比响应中 Last-Modified 是否与 .gz 文件的修改时间一致
• 若变慢，大概率是 .gz 缺失或 mtime 不同步，Nginx 会多一次 stat() 系统调用后退到动态压缩

与其他压缩配置协同：gzip_static 是主路径，gzip on 是兜底

两者可共存，但角色清晰：

• 保持 gzip on 在全局 http 块开启——用于处理漏掉的静态类型、动态接口（如 API JSON）、或未生成 .gz 的边缘情况
• gzip_static on 只出现在静态资源 location 中，作为 JS/CSS/HTML 等资源的首选响应路径
• CDN 场景下，务必关闭后端 gzip（即 gzip off 在 proxy_pass 上游配置中），否则 CDN 可能缓存错误版本
• 不需要配置 gzip_types 给 gzip_static ——只要存在同名 .gz，就尝试返回