直接启用gzip_static on可让Nginx优先返回同名.gz文件，跳过实时压缩以降低CPU开销；需前端构建时生成.gz文件并保留原文件，Nginx配置中在对应location块启用gzip_static on、gzip on和gzip_vary on，并通过curl和日志验证生效。
直接启用 gzip_static on 即可让 Nginx 优先查找并返回同名 .gz 文件，跳过实时压缩过程，从而几乎消除静态资源响应时的 CPU 开销。
前端构建阶段：生成 .gz 文件并保留原始文件
React/Vue 等 SPA 构建默认不产出压缩文件，需主动引入预压缩步骤：
- 使用
compression-webpack-plugin（Webpack）或vite-plugin-compression（Vite），配置deleteOriginalAssets: false—— 这是关键，必须保留main.js和main.js.gz共存 - 推荐阈值设为
10240（10KB），避免压缩过小文件得不偿失 - 确保生成的
.gz文件与源文件时间戳一致（插件通常自动处理），否则 Nginx 可能拒绝使用
Nginx 配置要点：启用 + 路径匹配 + 协同设置
gzip_static 不依赖 gzip_types，但需与其他 gzip 指令配合才能稳定生效：
- 在服务静态资源的
location块中启用：gzip_static on; - 全局或该 location 中开启基础 gzip：
gzip on;（作为兜底，当 .gz 缺失时自动降级） - 添加
gzip_vary on;，确保 CDN 或代理能正确缓存不同编码版本 - 禁用老旧客户端兼容项如
gzip_disable "MSIE [1-6]\.";，避免干扰现代浏览器判断
验证是否生效：三步确认法
不能只看配置是否写上，要实测行为：
- 用
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/static/js/main.xxxx.js查看响应头是否有Content-Encoding: gzip且Content-Length明显变小 - 检查 Nginx 错误日志，若出现
open() "/path/to/file.js.gz" failed (2: No such file)，说明构建漏了 .gz 或路径不匹配 - 对比开启前后服务器 CPU 使用率（尤其高并发时 JS/CSS 请求密集期），下降明显即说明成功卸载了压缩负载
整个机制不复杂但容易忽略细节：构建出 .gz、Nginx 找得到、原始文件还在、兜底 gzip 开着——四者齐备，CPU 负载就能稳稳降下来。
