Nginx gzip 压缩怎么开？文本类型、CPU 开销与缓存验证
网页传输体积很大时，压缩可能有帮助，但前提是内容本身仍有可压缩空间。已经压缩的图片、视频和归档文件，继续 gzip 往往收益有限。本文以 Nginx 提供公开静态资源为例，讨论如何选择范围和观察结果，不把任何参数当成固定的性能承诺。
先看哪些资源占用了下载量
在浏览器网络面板中找出传输较大的文本文件，区分 CSS、JavaScript、JSON 与图片、视频。比较传输大小和解压后的资源大小，先确认是否已经被应用、CDN 或源站压缩。重复添加配置而不检查现状，可能只增加复杂度。
如果页面慢在数据库处理或外部接口，压缩静态文件并不能缩短那段等待。将问题拆成响应开始时间、传输体积与浏览器执行时间，再决定压缩是否是当前值得处理的环节。
只在明确的资源范围启用
下面演示为已经配置好文件映射的公开静态资源 location 增加 gzip 选项，保留原有 root 或 alias 设置：
# 加入既有的公开静态资源 location
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
gzip_min_length 1024;
gzip_comp_level 4;
gzip_vary on;
文件类型由响应的 Content-Type 决定，不是仅看扩展名。最小长度和压缩等级都是用于开始验证的示例值，应根据文件规模和实际 CPU 余量调整。更高等级可能增加计算成本，不能未经测试就认定更高一定更好。Nginx gzip 模块文档
已有全站压缩、预压缩文件或 CDN 压缩时，先明确由谁负责。不要把示例直接塞进敏感动态页面范围；包含秘密值和攻击者可影响内容的压缩响应，需要按应用的安全设计评估。
检查客户端协商和实际响应
在 Linux 或 macOS 终端对自己的真实静态文件测试：
curl -I -H 'Accept-Encoding: gzip' https://example.com/assets/site.css
curl --compressed -sS -o /dev/null -w 'download=%{size_download}\n' https://example.com/assets/site.css
Windows PowerShell 使用独立的 curl.exe，并将输出丢弃到 Windows 的 NUL 设备：
curl.exe -I -H 'Accept-Encoding: gzip' https://example.com/assets/site.css
curl.exe --compressed -sS -o NUL -w 'download=%{size_download}\n' https://example.com/assets/site.css
第一条检查响应头，第二条发送支持压缩的请求并读取实际响应。确认 Content-Encoding、Content-Type 与缓存相关头符合预期。小文件或不符合配置类型的资源未压缩，可能是预期行为，不要据此继续扩大所有类型。
Content-Encoding 描述的是表示内容采用的编码方式，客户端需要按对应方式解码。不能手工增加 gzip 响应头却仍发送未压缩正文，否则浏览器可能无法正确读取。MDN Content-Encoding 说明
比较效果时保持测试条件一致
选择同一个文件、相近网络条件和相同访问入口，分别观察压缩与未压缩时的传输量。不要把一次 CDN 命中与一次源站未命中直接比较，也不要用浏览器已缓存的零下载结果证明压缩比很好。
同时观察服务器 CPU、响应时间和错误率，尤其在高峰负载下。若减少了一些流量却让应用响应明显变慢，应降低强度、缩小范围，或评估在构建阶段生成预压缩资源。静态文件更新时，预压缩副本也必须同步更新，不能让两份内容版本不同。
共享缓存需要区分客户端可接受的编码，相关 Vary 行为应与 CDN 设置协调。验证不同客户端都能得到可解码的正文，避免缓存把一种表示错误发送给另一类客户端。
配置回退与后续发布检查
修改前保存原有配置，执行 sudo nginx -t，通过后重新加载。验收至少覆盖一个较大文本文件、一个小文件、一个已压缩图片和一个不存在资源，检查正常内容与错误响应都没有被破坏。
如果出现解码错误或资源异常，恢复本次压缩配置并验证缓存中的对象，必要时按所用缓存系统的正式方式更新相关资源。日后构建工具、资源类型或 CDN 发生变化时重新检查，不要让曾经有效的压缩规则变成无人维护的历史设置。