必须设 gzip_min_length，因为小文件（如200字节JSON）压缩后可能因gzip头部10–20字节开销而体积反增、白耗CPU；推荐值1024字节，兼顾压缩收益与性能，且须配合 gzip on、gzip_types、gzip_vary 等参数并用curl验证生效。
直接设 gzip_min_length 就行，关键是设对数值、配好配套参数，否则写了也白写。
为什么必须设 gzip_min_length
小文件（比如 200 字节的 JSON 返回、300 字节的健康检查接口）压缩后反而可能变大——gzip 格式自带 10–20 字节固定开销，内容太短时，压缩收益被开销吃掉，还白耗 CPU。设了这个值，Nginx 就会跳过这些“不划算”的响应。
推荐值：1024 字节（1KB）
这是经过大量实测的平衡点：
- 低于 1KB 的 HTML/CSS/JS 很少有压缩价值，比如内联脚本、简单 API 响应
- 1KB 能覆盖大多数有意义的文本内容（如带样式的 HTML 片段、轻量 JS 模块）
- 设成 512 或 256 收益微乎其微，CPU 开销却明显上升；设为 0（默认）等于放弃防护
必须配合的关键配置
单独设 gzip_min_length 不起作用，得和这几个一起用：
-
gzip on;—— 必须开启，否则所有压缩参数都无效 -
gzip_types application/javascript text/javascript text/css text/html;—— JS、CSS 等类型必须显式列出，Nginx 默认不包含application/javascript -
gzip_vary on;—— 让 CDN 和浏览器知道响应可能被压缩，避免缓存错发 - 确保客户端请求头含
Accept-Encoding: gzip，否则压了也传不出去
怎么验证它真生效了
不能只看配置写了没，得测真实响应：
- 用 curl 测一个小文件：
curl -I -H 'Accept-Encoding: gzip' http://your-site/health - 如果响应头里没有
Content-Encoding: gzip，且Content-Length是原始大小，说明过滤成功 - 再测一个 2KB 的 JS 文件，应看到
Content-Encoding: gzip和明显减小的Content-Length
