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