开启 gzip_static on 可使 Nginx 直接发送预压缩的 .gz 文件，跳过实时压缩，CPU 开销趋近于零；需构建时用 compression-webpack-plugin 生成 .gz 文件（deleteOriginalAssets: false），部署时保持文件共存与时间一致，并在 location 块中仅配置 gzip_static on。
直接用 gzip_static on 就能跳过实时压缩，把 CPU 开销降到几乎为零——前提是构建时生成 .gz 文件、部署时保留原始文件、Nginx 配置不踩坑。
构建阶段：让打包工具产出 .gz 文件
React/Vue 等前端项目默认不生成 .gz 文件，必须主动加插件。以 Webpack 为例，推荐使用 compression-webpack-plugin（v9+ 支持 Webpack 5）：
-
关键配置项：
deleteOriginalAssets: false（必须设为 false），确保 .js/.css 原文件和同名 .gz 文件共存于输出目录； -
合理阈值：
threshold: 10240（10KB），避免对极小文件压缩，得不偿失； -
匹配范围：覆盖
.js、.css、.html、.svg等文本类资源，图片和字体无需压缩。
执行 npm run build 后，你会看到类似 main.a1b2c3d4.js 和 main.a1b2c3d4.js.gz 成对出现。
部署阶段：保持文件结构与时间一致性
Nginx 查找 .gz 文件时，只看路径是否存在，不校验修改时间——但浏览器缓存依赖 Last-Modified，所以建议同步时间：
- 用
touch -r source.js source.js.gz把 .gz 文件的修改时间设为和原文件一致； - 部署脚本中可批量处理：
find ./build -name "*.js.gz" -exec touch -r {}\.js {} \;； - 务必确认 Nginx 用户（如 www-data）对 .gz 文件有读取权限。
Nginx 配置：正确启用并避免常见陷阱
只需两处关键设置，无需额外 gzip_types 或 gzip on：
- 在
location /或静态资源 location 块内添加gzip_static on;； -
不要写
gzip_types—— 它对gzip_static完全无效； -
不要关掉
gzip on（如果已开启）——它作为兜底：当 .gz 缺失时仍可动态压缩； - 验证是否生效：用
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/static/js/main.js，响应头应含Content-Encoding: gzip且Content-Length接近 .gz 文件大小。
为什么比动态 gzip 更高效？
核心差异不在“压得更狠”，而在“压的时机”：
- 动态 gzip：每次请求都读文件 → CPU 压缩 → 写响应流，无法用 sendfile 零拷贝；
- gzip_static：直接 open + sendfile 发送 .gz 文件，纯磁盘 IO，无 CPU 计算；
- 实测显示，高并发下 CPU 使用率可下降 30%~60%，首屏资源加载延迟减少 10%~20%。
