Brotli比Gzip在JS、HTML、JSON上压缩率分别高15%–18%、12%–15%、约10%，但对随机或已压缩内容无优势；Nginx需启用brotli_static与gzip_static并预生成文件，解压性能需权衡——推荐Brotli level 4–5，Gzip level 6。
直接对比 Brotli 与 Gzip 的压缩率差异，不能只看配置开关或理论值，得在真实资源、相同条件下实测——因为压缩率高度依赖内容类型、长度、重复模式，以及你用的压缩参数。
用同一组静态文件做基准测试
选一批典型生产资源：比如一个 120KB 的打包 JS、一个 45KB 的 HTML 模板、一个含大量字段的 8KB JSON 响应。确保这些文件未被其他工具（如 Webpack）二次压缩过。
- 用 brotli -q 6 -k file.js 生成
file.js.br - 用 gzip -6 -k file.js 生成
file.js.gz - 对比原始大小、.br 大小、.gz 大小，计算压缩率：
(1 − 压缩后/原始) × 100%
你会发现：JS 文件上 Brotli 通常比 Gzip 多压 15%–18%，HTML 高出 12%–15%，而纯随机字符串或已压缩的 PNG 则几乎无差别——这也说明不是所有资源都值得开 Brotli。
在 Nginx 中验证运行时效果
光看本地命令行结果不够，还得确认 Nginx 实际返回的是哪个版本。方法很简单：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用 curl -H "Accept-Encoding: br" -I https://yoursite.com/app.js 查看响应头是否含
Content-Encoding: br，并记下Content-Length - 再用 curl -H "Accept-Encoding: gzip" -I https://yoursite.com/app.js 对比
Content-Length - 两者差值就是该请求路径下真实的带宽节省量
注意：必须确保 brotli_static on 和 gzip_static on 都启用，并且磁盘上存在对应 .br 和 .gz 文件；否则 Nginx 会退回到动态压缩，CPU 开销和结果都会波动。
看压缩率还要结合解压成本
压缩率高不等于体验好。Brotli q=6 的解压速度和 Gzip level=6 接近，但 q=11 虽然再省 2–3KB，却会让低端手机首屏渲染延迟明显上升。真实压测数据显示：在中端安卓机上，Brotli q=11 解压一个 200KB JS 比 q=6 多花 47ms，而用户可感知卡顿阈值是 30ms。
- 推荐策略：HTML/CSS 用
brotli_comp_level 5，API JSON 响应用4，兼顾压缩率与终端解压效率 - Gzip 保持
gzip_comp_level 6即可，再往上提升有限，CPU 反而翻倍
别忽略缓存与 CDN 层的影响
如果用了 CDN，它可能自己做了压缩或覆盖了你的 Vary 头。务必检查最终用户收到的响应头里是否有：
-
Vary: Accept-Encoding—— 缺失会导致 CDN 缓存混用，本该返回 .br 却给了 .gz -
Content-Encoding和Content-Length是否与你本地测试一致
建议在 CDN 后台开启“按 Accept-Encoding 分片缓存”，并在边缘节点设置 brotli_static always（部分 CDN 支持），避免回源时反复判断。
