核心是启用gzip_static模块并预生成同名.gz文件，Nginx直接返回零CPU开销；需确认模块已编译、显式开启gzip_static on、文件路径权限正确、时间戳不早于原文件，并配合gzip_types精确控制类型。
要实现 CPU 零开销的静态资源 Gzip 传输，核心是让 Nginx 不在请求时实时压缩，而是直接读取你提前生成好的 .gz 文件，并原样返回给客户端。这正是 http_gzip_static_module 模块的设计目的——它不压缩，只“搬运”。
确认模块已启用并正确配置
Nginx 默认可能未启用该模块（尤其在精简版或某些发行版中）。先检查是否已编译进 Nginx：
nginx -V 2>&1 | grep -o with-http_gzip_static_module
若无输出，需重新编译 Nginx 并加入 --with-http_gzip_static_module 参数。启用后，在 http 或 server 块中开启：
-
gzip_static on;—— 必须显式开启，否则模块不生效 -
gzip_vary on;—— 推荐开启，让缓存代理知道响应取决于Accept-Encoding -
add_header Vary Accept-Encoding;—— 显式添加头，增强兼容性
按规范命名并存放 .gz 文件
模块不会自动压缩，只查找同名 .gz 文件。规则严格：
- 原始文件如
/static/js/app.js，需存在同路径下的/static/js/app.js.gz - 文件权限需与原始文件一致，且 Nginx worker 进程有读取权限
- 不支持
.gz文件时间戳早于原始文件（Nginx 会跳过，降级为发送未压缩版） - 不校验
.gz内容是否真实可解压，错误压缩会导致客户端报错
配合 gzip_types 精确控制匹配范围
gzip_static 只对满足 gzip_types 列表的 MIME 类型生效。例如：
gzip_types text/css application/javascript application/json;- 避免写
gzip_types *;—— 不安全，且部分类型（如图片）本就不该 Gzip - 确保前端请求带
Accept-Encoding: gzip（现代浏览器默认携带）
验证是否真正零开销
成功时，Nginx 日志中 $sent_http_content_encoding 应为 gzip，且响应体直接来自 .gz 文件：
- 用
curl -H "Accept-Encoding: gzip" -I http://yoursite/static/app.js查看响应头 - 对比
Content-Length与本地app.js.gz文件大小是否一致 - 监控 CPU 使用率：高并发下，相比开启
gzip on，worker 进程 CPU 应明显更低
不复杂但容易忽略——关键在预压缩质量、文件路径一致性、以及模块开关状态。只要 .gz 文件就位且配置无误，Nginx 就只是打开文件、发出去，全程无压缩计算。
