选Gzip还是Brotli取决于场景：Gzip兼容性好、开销低，适合全量用户或CPU紧张环境；Brotli压缩率高12%–20%，但需现代浏览器支持，推荐用于静态资源预压缩场景。
选 Gzip 还是 Brotli，关键不在“哪个更好”，而在“谁更适配你的场景”。Gzip 兼容性好、开销低、响应快；Brotli 压缩率高，但压缩过程更耗 CPU，且需客户端支持（现代主流浏览器均支持，IE 全系不支持）。真实压测中，Brotli 对 HTML/JS/CSS 的压缩率通常比 Gzip 高 12%–20%，但压缩耗时可能多出 2–3 倍。
什么时候该用 Gzip
Gzip 是默认安全选择，尤其适合以下情况：
- 服务面向全量用户（含旧版浏览器或嵌入式客户端）
- CPU 资源紧张，比如小规格云服务器、高并发 API 网关
- 内容以动态生成为主（如模板渲染的 HTML），无法预压缩
- 已有成熟运维流程，不愿引入编译依赖或额外模块
什么时候值得上 Brotli
Brotli 的优势集中在静态资源和可控环境，推荐在这些条件下启用：
- 站点主力用户为 Chrome/Firefox/Safari/Edge（即基本排除 IE）
- 有大量静态文本资源（如文档站、博客、前端 SPA 的构建产物）
- 已对关键资源做预压缩（
brotli -Z打包），Nginx 只需提供br文件服务，几乎零运行时 CPU 开销 - 带宽成本显著高于计算成本（例如 CDN 回源流量贵、海外节点出口受限）
Gzip 配置的关键调优点
不盲目设 gzip_comp_level 9，实际收益极小，CPU 却明显上升。建议按需分层：
-
API 接口类服务：设为
gzip_comp_level 3，兼顾速度与基础压缩（HTML/CSS/JS 仍可减 40%+ 体积） -
通用 Web 站点：设为
6，平衡点明确，HTML 常压缩 70%、JS/CSS 达 65% -
务必开启
gzip_vary on，否则 CDN 或代理可能缓存错乱 -
慎用
gzip_min_length 20，太小会压缩大量无效小响应（如空 JSON），建议设为1024（1KB）起
Brotli 部署的实用提醒
Brotli 不是“开个开关”就完事，落地有几个硬门槛：
- 必须通过源码编译 Nginx 加载
ngx_brotli模块，宝塔等面板需手动添加自定义模块并重装 - 运行时压缩（
brotli on）对 CPU 压力大，生产环境更推荐 静态预压缩 +sendfile on直接投递 .br 文件 - 需同时保留 Gzip 配置作为 fallback：浏览器若不申明
br，仍可用gzip降级 - 验证是否生效不能只看响应头，要对比
Content-Encoding: br和未压缩大小，推荐用curl -I -H 'Accept-Encoding: br' example.com/app.js
