直接读取预压缩的.gz文件是节省Nginx CPU最有效方式：构建阶段生成同名.gz文件并同步时间戳，Nginx在location块中启用gzip_static on且与全局gzip on兜底共存，curl验证Content-Encoding: gzip及文件存在性。
直接让 Nginx 读取已存在的 .gz 文件，跳过实时压缩计算，是节省 CPU 最立竿见影的方式。关键不是“开不开 gzip”，而是构建时生成 .gz + Nginx 在正确位置启用 gzip_static on。
前端构建阶段：必须产出同名 .gz 文件
所有静态资源（JS、CSS、HTML、SVG、JSON、woff2 等）需在打包时就生成对应 .gz 版本，不能等请求来了再压。
-
Webpack 项目：用
compression-webpack-plugin，核心配置：algorithm: 'gzip'、deleteOriginalAssets: false（必须保留原始文件）、threshold: 10240（只压 ≥10KB 的文件，避免小文件得不偿失） -
Vite 项目：用
vite-plugin-compression，设algorithm: 'gzip'、ext: '.gz'，同样保留源文件 -
已上线补救：对静态目录批量生成，例如：
find /usr/share/nginx/html -type f \( -name "*.js" -o -name "*.css" -o -name "*.html" \) -exec gzip -c9 {} \; -exec mv {}.gz {}\.gz \;
生成后建议同步时间戳：touch -r main.js main.js.gz，避免缓存行为异常
Nginx 配置：精准落在资源服务路径下
gzip_static on 不是全局开关，必须写在真正提供静态文件的 location 块里，否则不生效。
- 常见 SPA 配置中，加在
location / { ... }内部即可，例如：location / {<br> root /usr/share/nginx/html;<br> try_files $uri $uri/ /index.html;<br> gzip_static on;<br>} - 也可用正则精确匹配后缀：
location ~* \.(js|css|json|svg|woff2?|ttf|eot)$ { gzip_static on; } -
不需要配
gzip_types——gzip_static对类型无限制，只要磁盘上有同名 .gz 就尝试返回 -
不要在同一 location 里重复写
gzip on，二者职责不同：前者专用于预压缩静态文件，后者应放在 http 块做兜底
协同策略：gzip_static + gzip 共存但分工明确
推荐两者共存，但各司其职，兼顾性能与容错。
-
gzip_static on处理已预压缩的静态资源，CPU 开销趋近于零 -
gzip on放在http块顶层，作为兜底：处理动态接口、漏掉的静态文件或未生成 .gz 的资源 - 兜底 gzip 推荐配置：
gzip_min_length 1000、gzip_comp_level 4（平衡速度与压缩率）、gzip_vary off（避免 CDN 缓存分裂） - 注意执行顺序：
gzip_static在try_files之前生效；若重写路径导致原始 URI 变化，.gz 可能找不到
验证是否生效
上线后务必检查三件事，缺一不可：
-
磁盘上是否存在同名 .gz 文件（如
main.js和main.js.gz同目录） -
响应头是否含
Content-Encoding: gzip（用 curl 或浏览器开发者工具查看） -
错误日志是否报
open() "/xxx.js.gz" failed（说明路径或权限问题）
