gzip压缩实践指南：从Nginx配置到前端资源优化

我做了七八年后端和前端性能优化，接触过各种压缩方案，从最早的 zip 到后来的 brotli、zstd，但gzip始终是那个"最不惊艳、但最可靠"的存在。最近把手里几个项目重新梳理了一遍，从 Nginx 配置到前端构建产物，从文本压缩到二进制资源，把 gzip 的实践笔记完整整理出来。这篇文章会从原理讲到参数选型，再讲配置落地的完整链路，以及我在真实环境里踩过的那些坑。如果你是刚接触服务端性能优化的新人，或者已经在用 gzip 但没深入理解它，这篇应该能帮你少走不少弯路。

1. 为什么我最后回到 gzip：静态资源体积治理的实测账单

1.1 三套压缩方案横向对比后的选择逻辑

先交代一下背景。我手上有两个 Web 项目，一个是传统服务端渲染的管理后台，前端资源由 Webpack 打包；另一个是前后端分离的电商 H5，静态资源放在 CDN 上。两个项目都有明显的体积焦虑：管理后台首屏 JS 打包后接近 1.2MB，H5 那边更夸张，一个首屏页面涉及的 JS、CSS、JSON 总共将近 3MB。

一开始我试过直接上 brotli，Compression Streams 和现代浏览器对它的支持已经很好，压缩率确实比 gzip 高出 10% 到 15%。但问题在于，我们的 CDN 服务商对 brotli 的支持并不稳定，部分边缘节点会回退到未压缩状态。我也试过 zstd，在服务端到服务端的传输场景里表现极佳，但浏览器端的解压支持到目前依然不够理想。绕了一圈，最终所有静态资源全部回到 gzip。

这里有一个容易被忽略的核心认知：gzip 不是压缩率最高的方案，但它拥有最完整的生态兼容性。任何 HTTP 客户端、任何 CDN、任何反向代理，甚至十年前的老浏览器，都能正确处理 gzip。对线上环境来说，稳定性永远比那几个百分点的压缩率更重要。

1.2 数据压缩前后的真实体积变化

直接看我这边的实测数据。管理后台项目里的一个核心 JS 文件，未压缩时 284KB，gzip 压缩后是 81KB，压缩率约 71.5%。一个包含大量中文文案的 JSON 配置，原始 146KB，gzip 后只剩 23KB，压缩率 84.2%。CSS 文件的效果更夸张，因为样式表里大量重复的选择器和属性名，一个 96KB 的样式文件压缩到 12KB。

从传输时间维度看效果更直观。按常规 4G 网络 10Mbps 下行速率估算，一个 284KB 的文件传输大约需要 230ms，压缩到 81KB 后只需要约 65ms，首屏渲染的阻塞时间直接减少了 160ms 以上。这还只是单个文件，如果按一个页面加载 20 个静态资源计算，总体节省的时间非常可观。

1.3 gzip 的应用场景边界与适用判断

gzip 适合压缩什么？以我的经验，以下类型收益最大：

• 文本类资源：JS、CSS、HTML、SVG、JSON、XML。
• API 响应体：尤其是接口返回的大 JSON，开启 gzip 后体感明显。
• 服务端渲染的页面 HTML：动态生成的页面，直接压缩后输出。

不适合压缩的包括：已经压缩过的图片格式（JPEG、PNG、WebP）、视频（MP4、WebM）、音频（MP3、AAC），以及压缩包本身。这些格式内部已经做过了压缩处理，gzip 再压一遍不仅体积几乎不变，反而浪费 CPU。

还有一个容易忽略的点：极小文件不建议启用压缩。文件小于 1KB 时，gzip 添加的头部信息和字典开销可能让压缩后的体积反而大于原始体积。所以实际配置时我都会设置最小压缩阈值，Nginx 里的默认值是 20 字节，我习惯调高到 256 字节，小于这个大小的文件直接不压缩。

2. 压缩级别与 CPU 开销的博弈：deflate 参数到底怎么选

2.1 gzip 背后的 deflate 算法与 LZ77 原理简化理解

gzip 的核心算法是 deflate，它由两个部分组成：LZ77 编码和 Huffman 编码。理解这两个部分，你就知道为什么选参数会有这么多门道。

LZ77 的原理用一句话概括：用"重复内容的引用"代替重复内容本身。它会扫描整个数据流，维护一个滑动窗口，如果发现当前内容在窗口内已经出现过，就用一个长度和距离的标记去指向之前的位置。比如一个文件里连续出现 10 次"performance optimization"，LZ77 会在第二次出现时只记录"从多远的位置开始，长度是多少"，然后直接跳过去。这就是为什么带大量重复代码片段或重复样式规则的文本，压缩率会特别高。

Huffman 编码的第二阶段，则是对前面输出的标记和字面量再次编码，把出现频率高的符号用更短的二进制位表示。你如果用过哈夫曼树，应该对这个不陌生。两阶段叠加，就是 deflate 的全部逻辑。了解了这个原理，就明白了为什么 gzip 压缩文本文件能有 80% 以上的压缩率，而压缩图片却几乎无效。

2.2 压缩级别 1 到 9 的取舍与我的实测数据

gzip 的压缩级别从 1 到 9，数字越大，压缩率越高，但耗时也越长。很多人直接默认级别 6，或者干脆用最高级别 9，但这其实不一定是最优解。

我用一个 500KB 的 JavaScript 文件做了基准测试，在同一台机器上：

从这份数据能看到：级别 1 到 6 之间，压缩率提升非常明显，但耗时也在逐步增加；级别 6 到 9 之间，压缩率只提升了约 5%，耗时却翻了一倍以上。

这里要分场景看。如果压缩发生在请求时（动态压缩），级别 6 是性能和压缩率的平衡点；如果压缩发生在构建时（静态预压缩），建议直接用级别 9，因为构建多花的时间换来的是每个用户的传输速度提升，这笔账非常划算。我在 Webpack 里配置 CompressionWebpackPlugin 时，都是直接设成 level 9。

2.3 影响压缩率的两个隐藏参数：windowBits 和 memLevel

除了压缩级别，zlib 库还有两个参数，windowBits 和 memLevel，很多人根本没碰过，但它们在特定场景下对压缩率有显著影响。

windowBits 控制 LZ77 滑动窗口的大小，默认值是 15，对应 32KB 窗口。窗口越大，算法能看到的历史数据越多，找重复内容的能力越强。对于大文件，把 windowBits 从 15 增到 23（对应 8MB 窗口）能进一步提升压缩率，但内存开销会呈指数增长。我试过把一个 4MB 的 JSON 文件用 windowBits=23 压缩，比默认设置又缩小了约 3% 到 5%。不过这个参数必须和压缩级别配套，zlib 里 windowBits 设得太大，压缩级别低时会报错。

memLevel 则控制压缩过程中的内存使用量，取值范围 1 到 9，默认 8。memLevel 越大，分配的内部缓存越多，压缩速度越快，压缩率也略微提升。常规场景保持默认即可，但如果你的服务器内存紧张，把 memLevel 降到 4 或 5 可以明显减少内存占用，压缩率损失约 1% 左右。

2.4 针对不同资源类型的分级压缩策略

既然不同参数各有优劣，一个聪明的做法是按资源类型设置不同的压缩级别。我不会对所有文件一视同仁。

CSS 和 JS 这两个前端核心资源，我使用级别 9 和最大的 windowBits，因为它们是构建产物，可以提前预压缩，不消耗运行时 CPU。API 接口返回的 JSON，响应体大小波动大，而且不能预压缩，我用级别 6，保证压缩率的同时避免接口延迟。纯文本日志文件，如果走服务端压缩下载，用级别 3 到 4 就够了，因为日志里重复内容太多，低级别已经能吃掉大部分冗余，没必要浪费 CPU。

3. 服务端与前端链路配置：Nginx 和构建工具的完整落地

3.1 Nginx 开启动态 gzip 的标准配置与参数说明

绝大多数场景下，Nginx 是承担 gzip 压缩的主力。它在反向代理层直接压缩响应，对后端应用完全透明，改配置即可，不用动代码。

我在 Nginx 里的标准配置如下：

nginx复制gzip on;
gzip_comp_level 6;
gzip_min_length 256;
gzip_buffer 16 8k;
gzip_proxied any;
gzip_types text/plain text/css application/json application/javascript application/xml application/xml+rss image/svg+xml;
gzip_vary on;
gzip_disable "MSIE [1-6]\.";

这里每个参数都有讲究。gzip_comp_level 6 是动态压缩的折中选择，前面已经说过原因。gzip_min_length 256 避免压缩小文件。gzip_buffer 16 8k 设置压缩响应的缓冲区大小，Nginx 会分成 16 个 8KB 的内存块来缓冲压缩数据，减少磁盘 I/O。gzip_proxied any 控制对代理请求的处理，这里的 any 表示只要客户端通过代理发送了 Accept-Encoding 请求头，不管是否来自 CDN，都直接压缩。

gzip_vary on 特别重要，它会让 Nginx 在响应头里加上 Vary: Accept-Encoding，这样缓存系统就能根据不同的编码方式缓存不同版本，避免 CDN 把 gzip 版本的内容发给不支持 gzip 的客户端。

3.2 前端构建产物与构建期预压缩

如果只是在 Nginx 层做动态压缩，意味着每次请求都要消耗 CPU 来压缩。对于访问量大的站点，这和直接预压缩相比浪费了不少计算资源。更好的方案是在构建阶段生成 .gz 文件，Nginx 直接返回静态文件。

在 Webpack 中使用 CompressionWebpackPlugin：

javascript复制const CompressionPlugin = require('compression-webpack-plugin');

module.exports = {
  plugins: [
    new CompressionPlugin({
      filename: '[path][base].gz',
      algorithm: 'gzip',
      test: /\.(js|css|html|svg|json)$/,
      threshold: 1024,
      minRatio: 0.8,
      compressionOptions: {
        level: 9,
        windowBits: 23
      }
    })
  ]
};

这里 threshold: 1024 表示只有大于 1KB 的文件才生成 .gz 版本。minRatio: 0.8 是个关键参数，它代表如果压缩后体积比原始体积小不到 20%，就不生成压缩文件。这是为了避免那些本来就压不动的内容（比如内嵌 base64 图片的 CSS）浪费一个额外的请求开销。compressionOptions 里的 level 和 windowBits 直接传入 zlib，在构建期我们就可以放心用最高级别。

构建完成后，dist 目录里会出现 .js 和 .js.gz 成对的文件。接下来 Nginx 需要做的是在静态文件服务中启用 gzip_static：

nginx复制gzip_static on;
gzip on;
gzip_min_length 256;

gzip_static on 的意思是，当请求一个文件时，Nginx 会优先寻找对应文件的 .gz 版本，如果存在就直接返回，不再执行动态压缩。这比动态压缩快得多，因为省去了整个压缩计算过程。剩下的 gzip 指令则作为兜底，处理那些没有预压缩文件的请求。

3.3 Node.js 服务端针对接口和 HTML 的压缩实践

如果你的应用跑在 Node.js 上，处理动态接口和 SSR 页面时同样可以启用 gzip。以 Express 为例，最方便的方式是使用 compression 中间件：

javascript复制const compression = require('compression');
const express = require('express');
const app = express();

app.use(compression({
  level: 6,
  threshold: 1024,
  filter: (req, res) => {
    if (req.headers['x-no-compression']) {
      return false;
    }
    return compression.filter(req, res);
  }
}));

这个中间件的原理就是检查请求头的 Accept-Encoding，对支持的客户端自动压缩。filter 函数让我可以实现精细控制，比如某些内部接口可以通过自定义请求头来跳过压缩，降低 CPU 消耗。

在 Node 层还有一个细节：一定要避免重复压缩。如果 Nginx 已经在代理层做了一次 gzip，Node 再压缩一次就叫 double compression，在 Nginx 中可以通过 gzip_proxied 来控制。这里的关键是让 Nginx 知道上游是否已经压缩过，Nginx 会根据上游响应头里的 Content-Encoding 来判断。只要 Node 中间件正确设置了 Content-Encoding，Nginx 就不会重复压。

3.4 CDN 回源压缩的配置和各层级的联动编排

上线到 CDN 后，压缩链路又多了一层。通常 CDN 有三种回源模式：源站不压缩，CDN 边缘节点压缩；源站压缩，CDN 透传；源站预压缩，CDN 透传。第三种是我最推荐的。

我的实践是：Webpack 构建产物预压缩，源站 Nginx 开启 gzip_static 直接返回 .gz 文件，同时配置 gzip_vary on。CDN 回源拿到已经压缩好的文件，直接缓存到边缘节点。用户请求资源时，CDN 边缘节点会检查请求里的 Accept-Encoding，如果有 gzip 就返回缓存的压缩版本，如果没有就透传原始版本（前提是预压缩时保留原始文件）。

这个链路里最容易出问题的是 Vary: Accept-Encoding 头。如果 CDN 缓存时没有记录这个 Vary 头，它可能把 gzip 压缩的版本缓存下来，然后发给一个不支持 gzip 的老客户端，结果就是页面乱码。我排查过好几个线上故障最后都回到这个点。检查 CDN 控制台是否有忽略 Vary 头的选项，如果有，务必关掉。

4. 实测中踩过的坑：从压缩后乱码到动态压缩失控

4.1 压缩后乱码的完整排查链路与根因确认

有一次我接到反馈，生产环境首页 JS 文件加载后浏览器直接报语法错误，打开的页面一团糟，控制台显示"Unexpected token"。我一开始怀疑是代码引错了版本，但本地构建复现不出问题。然后我直接在浏览器里看响应头，发现 Content-Encoding: gzip，但文件内容并没有真正被压缩。也就是说，响应头声明的是 gzip，但响应体是原始未压缩内容，浏览器尝试用 gzip 解压普通文本，自然就会乱码。

这个问题的根因是上游已经用某种方式改变了响应体，但 Nginx 仍然按照它之前读取到的 Content-Type 和 Content-Encoding 做了处理。具体到我那个场景，是 Nginx 和后端服务之间有一层缓存，缓存服务器在某种条件下把压缩和未压缩的内容混存了，导致 Nginx 拿到的文件与响应头不匹配。

排查思路是逐步禁用链路环节。我先把 Nginx 配置里的 gzip_proxied any 改成 gzip_proxied off，问题依然存在，说明压缩不是发生在 Nginx 这一层；然后又直接请求后端源服务，跳过缓存层，发现内容正常。这样定位到是缓存层的问题，最后清除该缓存服务的全部缓存，并调整缓存键策略，加入 Accept-Encoding 作为维度，问题彻底解决。

这里提醒一句，排查乱码时不要只盯着 Nginx，向前看整个链路：客户端、CDN、Nginx、缓存、源服务器，任何一层都可能重写 Content-Encoding。最有效的定位手段是 curl 测试每一层返回的 header。

4.2 动态压缩在 CPU 满负荷时的失控事件

另一个坑是动态压缩在流量高峰时导致 CPU 被打满。那次是一个活动页面，瞬间涌入大量请求，Nginx 每响应一个请求就要做一次 gzip 压缩。虽然配置的是 level 6，但高峰期并发上千，压缩消耗的 CPU 成倍放大，最后 Nginx 的 worker 进程全部占用满，服务器几乎无响应。

这次事故之后，我做了一个反思：动态压缩从来都不适合高并发场景。高并发架构下的最优解是构建期预压缩 + gzip_static，让 Nginx 只做静态文件读取，不做任何压缩计算。

如果确实无法预压缩（比如动态接口），务必要在 Nginx 层做限流和缓存。对 API 接口，我额外加了一层响应缓存，相同请求参数的结果在 Nginx 直接返回缓存副本，不再回源。另外也可以把 gzip_comp_level 从 6 降到 4，在压力测试里，这个调整能把压缩消耗的 CPU 降低约 35%，压缩率仅损失约 2%。

4.3 预压缩文件被 CDN 透传时的浏览器兼容问题

还有一个在 CDN 环境里很隐蔽的问题。我们预压缩生成了 .gz 文件，Nginx 用 gzip_static 返回，CDN 回源拿到带 Content-Encoding: gzip 的响应，然后按照 CDN 的缓存策略缓存到边缘节点。到这里都没问题。

但问题出在 CDN 的透传模式上。有些 CDN 节点在缓存未命中时是直接透传回源响应，不做二次修改。当客户端发送的请求头是 Accept-Encoding: gzip，这个流程正常；但如果客户端是老版本浏览器，不支持 gzip，发的是 Accept-Encoding: identity，CDN 如果透传了源站返回的 gzip 内容，就会导致乱码或者无法解压。

怎么解决？最稳妥的办法是在 CDN 后台开启"自适应压缩"，让边缘节点根据客户端能力动态决定是否压缩。如果 CDN 不支持这个功能，就只能把 gzip_vary on 打开并确保缓存键包含 Accept-Encoding，这样 CDN 会为不同的编码方式缓存不同版本。我倾向于强制要求 CDN 启用该配置，不为兼容性问题留隐患。

4.4 压缩后的响应头与缓存策略兼容性处理

通常我们会在 Nginx 中设置 gzip 压缩后为静态资源加上长缓存时间。我的 Nginx 静态资源的缓存配置是这样的：

nginx复制location ~* \.(js|css|svg|json)$ {
    gzip_static on;
    expires 30d;
    add_header Cache-Control "public, immutable";
    add_header Vary "Accept-Encoding";
}

这里 Vary: Accept-Encoding 必须作为显式响应头加上，原因前面说过，确保缓存区和 CDN 能区分不同编码方式的版本。否则浏览器缓存中可能保存了 gzip 版本，下次在未携带 Accept-Encoding 的情况下直接复用，导致无法解码。

还有一个细节，immutable 这个值只对部分浏览器有效，但它表达的含义是"这个资源在过期时间内绝对不变"，配合内容哈希命名的文件非常合适。如果你们的前端资源命名没有带 hash，请一定不要加 immutable，否则用户会拿到旧的、改名前的缓存资源。

5. 进阶玩法：预压缩静态字典、跟 brotli 的联动及性能权衡

5.1 预定义字典压缩在特殊场景下的启发式应用

标准的 gzip 用的是固定字典（RFC 1951 定义的默认字典），它没有利用业务场景的先验知识。在某个特殊场景里，也就是一个 JSON 接口返回的数据里，大量字段名是固定的，比如 user_id、nickname、avatar_url、order_no 这些，它们反复出现在每条记录里。这时可以在服务端构建一个指定字典，让压缩器用这个业务字典来替代默认字典，压缩率能再提升一个层次。

zlib 提供了 setDictionary 方法，Node.js 的 zlib 模块也支持。思路是：从大量真实数据中提取高频字符串，拼接成一个字典文件，分别传入压缩器和解压器。需要注意的是，双方必须使用相同字典，否则解压会失败。

这个方案我建议只在传输层和后端服务之间使用，因为前端 JavaScript 里很难安全地保存和传递字典。如果你是在做一个低频更新但数据量极大的内部管理后台，这个思路值得试试；如果是公网前端资源，还是老老实实用默认配置。

5.2 gzip 与 brotli 的响应式选择策略

既然 brotli 压缩率更高，为什么我在某些链路里仍然保留 gzip？因为必须保证最低兼容底线。brotli 在 HTTPS 环境下已经覆盖了所有现代浏览器，但如果你还在服务某些老旧的 WebView 或非主流浏览器，brotli 就会出问题。

我一向的做法是"Nginx 同时启用 gzip 和 brotli 模块，根据请求头里的 Accept-Encoding 自动选择"。Nginx 的 ngx_brotli 模块会在安装了 brotli 静态模块后，自动识别请求头并决定是否用 brotli 压缩：

nginx复制brotli on;
brotli_comp_level 5;
brotli_types text/plain text/css application/json application/javascript application/xml image/svg+xml;

这里 brotli 的 brotli_comp_level 和 gzip 的 gzip_comp_level 是完全独立生效的。我实测过，brotli level 5 的压缩率已经超过 gzip level 9，但压缩速度依然快得多，所以在动态压缩场景中，如果客户端支持，优先使用 brotli。静态预压缩时，可以使用 brotli level 11，进一步减小体积。

5.3 按访问频率区分文件的关键路径优化

不是所有文件都值得花同样精力优化。我通常会按照热度把静态资源分成两类：一类是每个页面都会用到的公共包（框架代码、公共样式），另一类是低频工具页面的独立包。公共包我预压缩、加长缓存、CDN 预热，确保边缘节点始终有压缩版本；低频包则直接动态压缩，因为访问量少，压缩消耗的 CPU 可以忽略。

这个思路放到接口上也是一样。我在服务端建立了一个简单的压缩策略配置表：

这套分类策略让我可以精确控制 CPU 的消耗分布。热门资源全部用静态压缩，动态压缩的只有低频和接口数据，整体 CPU 开销大幅下降。

5.4 与 HTTP/2 服务端推送配合时需要注意的交互

如果你的服务端启用了 HTTP/2 服务端推送，有一个坑必须提醒：不要把 .gz 文件本身推送给客户端。很多 Nginx 配置在匹配静态资源时，会把 .gz 文件当成普通文件推送，结果客户端收到一个无法直接使用的压缩包。正确做法是推送原始文件，让 Nginx 根据 Accept-Encoding 自动决定是否返回压缩版本。

HTTP/2 多路复用本身已经减少了多次连接的开销，但 gzip 仍然能显著减小传输体积。在 HTTP/2 下资源请求并发度更高，所以压缩的作用不是减少连接数，而是减少每个流传输的字节数。这个层面的优化必须和预压缩配合，否则高频请求下 CPU 消耗会比 HTTP/1.1 更严重。

5.5 面向未来：zstd 的对比分析与迁移思考

最后聊聊 zstd。这是 Facebook 开源的无损压缩算法，在压缩速度和压缩率上同时超越 gzip 和 brotli。我在服务端到服务端的传输中用 zstd 做了几个实验，压缩率比 gzip 高约 10%，压缩速度是 gzip 的 5 倍以上。

但浏览器端的支持依然空白，所以目前无法替代 gzip 在 Web 场景的地位。我的判断是：未来如果所有主流浏览器都支持 zstd 解码，静态资源的压缩方案会全面转向它。目前可以先在服务端日志、数据备份、内部 API 服务之间使用 zstd，积累经验，等到浏览器支持成熟再平滑切换。通过 zlib 的 ZSTD_COMPRESS 或者命令行工具 zstd -19，可以很方便地在构建流程里增加一个 zstd 压缩产物，等未来某天时机到了，直接切换到新的 Content-Encoding 就行。

6. 压测验证与监控告警：压缩效果的量化评估方法

6.1 搭建一套简单的压缩效果压测方案

配置完成之后，不能只看浏览器里"已压缩"的标签就认为大功告成。我会用一套标准化的压测流程来验证实际效果。

压测工具有很多，我常用的是 wrk 和 curl。curl 主要是看单次请求的响应头是否正确，wrk 则用来测高并发下的 CPU 表现和 P99 延迟。命令大致这样：

bash复制wrk -t4 -c100 -d30s --header "Accept-Encoding: gzip" http://your-server/static/app.js

跑完会得到 Requests/sec、Transfer/sec 和延迟分布。我会把开启 gzip 前后两个结果放在一起对比，核心指标是转移字节数：开启 gzip 后 Transfer/sec 应该显著下降，Requests/sec 应该保持稳定甚至上升。

另外一个有用的指标是"节省的带宽"：分别用 curl 拉取带与不带 Accept-Encoding 的响应，对比 Body Size，这个值直接体现了压缩率。

6.2 响应头验证与缓存命中检查清单

每次压测完，我都会做一轮响应头检查，确保所有关键头部配置都对。以下是我的检查清单：

• Content-Encoding: gzip —— 响应确实被压缩。
• Vary: Accept-Encoding —— 缓存系统知道要区分编码版本。
• Cache-Control: public, max-age=xxx —— 静态资源缓存策略正确。
• Content-Length —— 压缩后大小合理，如果和原始文件一样大，说明压缩没生效。
• ETag —— 预压缩文件提供了正确的 ETag，避免返回错误版本。

在 Nginx 里，可以通过 $sent_http_content_encoding 变量把响应编码写入访问日志，方便线上验证：

nginx复制log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_accept_encoding" '
                '"$sent_http_content_encoding"';

这样日志里每一行都会记录客户端请求的编码能力和服务端实际返回的编码，排查问题会轻松很多。

6.3 线上压缩链路的关键监控指标

生产环境的压缩效果，我至少会盯三个监控指标：按域名和资源类型分组的 P50/P95 响应时间、Nginx 的 CPU 使用率、以及 Content-Encoding: gzip 的响应占比。如果 gzip 响应的占比突然下降，说明某个环节配置被改了或者 CDN 行为有变化，要及时排查。

另外还有一个容易忽略的监控：动态压缩的命中率和内存占用。当 Nginx 的 gzip_comp_level 设得过高且请求量大的时候，内存和 CPU 都会同步飙升。我会在监控里单独看 Nginx 进程的 CPU 和 RSS 内存曲线，一旦出现持续上涨就触发告警。

6.4 用 curl 命令梳理全链路压缩验证的方法

最后分享一个排查链路时经常用的 curl 组合命令，它可以一次性看到请求经过的各层返回头：

bash复制curl -I -H "Accept-Encoding: gzip" https://your-cdn-domain/static/app.js

这里 -I 表示只请求响应头，不会下载整个文件，请求速度很快。如果返回头里有 Via 字段，就能看到经过了哪些代理节点。我最关注的是 Content-Encoding 是否出现在最终响应中，以及 Age 字段是否表示命中缓存。如果 Age 大于 0，说明是 CDN 缓存命中；如果 Age 为空但响应头有 X-Cache: MISS，就说明这个请求走了回源链路。配合多点监测，可以快速定位问题是出在源站还是 CDN。

如果你用的是较新版本的 curl，还可以直接加 --compressed 参数，让它自动携带 Accept-Encoding: gzip 并在收到压缩响应时自动解压，这样直接查看内容是否完整，排查乱码问题非常高效。

gzip 这个技术本身很简单，但牵涉到的链路却很长。从构建工具到 Nginx，从 CDN 到客户端，每一个环节都有一两个不起眼的配置，出了问题却能让人排查一整天。我在实际项目里踩过的最深的坑，几乎都是"要么没看全链路，要么没验证响应头"。所以最后说一句心得：配置 gzip 不是打开开关就完事了，把你的配置清单、验证命令和监控指标固定下来，每次改动都跑一遍，线上出问题的概率会小很多。