Brotli 压缩等级需按内容类型分层设定：HTML 页面推荐 level 5，JSON API 推荐 level 4，过高会拖慢首字节时间并增加 CPU 压力。
Brotli 的 brotli_comp_level 不是“越高越好”，而是要按内容类型和访问场景分层设定。设错等级反而会拖慢首字节时间、增加 CPU 压力，尤其在移动端或高并发 API 场景下容易显现。
动态内容（HTML 渲染页、API JSON）用 3–5 级
这类响应由后端实时生成，压缩发生在每次请求时，必须控制耗时：
- HTML 页面（PHP/Node SSR 或模板渲染）推荐 brotli_comp_level 5：压缩率比 gzip 高约 19%，解压快，iOS/Android 主流机型解压 100KB 文本稳定低于 8ms
- API 接口返回的 JSON（如
/api/user）建议设为 4：小文件（ - 避开 0–1 级（增益仅比 gzip 高 5–8%，无实际价值）和 9–11 级（压缩耗时翻 2–3 倍，首字节延迟升高，弱网用户感知卡顿）
静态资源（JS/CSS/HTML 文件）可用 6–7 级
这些资源通常不频繁变动，且可配合构建阶段预压缩（.br 文件），服务端压力小：
- Vite/Webpack 构建时已生成
.js.br和.css.br，Nginx 启用brotli_static always后直接返回，此时brotli_comp_level不起作用；但作为兜底，仍建议设为 6 - 若未预压缩，纯靠 Nginx 动态压缩，6–7 是安全上限：再往上提升有限（+1%～2% 体积缩减），CPU 开销却陡增
别忽略配套参数，否则 level 再准也白搭
brotli_comp_level 要和几个关键参数协同生效：
-
brotli_min_length 256：小于 256 字节的响应（如空 JSON
{}）跳过压缩，避免小包反被塞进压缩流水线 -
brotli_types 必须精准：只列
text/html text/css application/javascript application/json image/svg+xml；加text/plain或通配符*可能误压二进制响应，导致乱码或解压失败 -
brotli_static off（动态压缩模式）或 always（预压缩优先）需明确指定；设成
on且无 .br 文件时会降级失败，不是“智能 fallback”
验证是否真生效，别只看配置
改完配置后务必实测：
- 用
curl -I -H "Accept-Encoding: br" https://yoursite.com/app.js查看响应头是否有content-encoding: br - Chrome DevTools → Network → 找一个 JS 请求 → 比较 Transfer Size：Brotli 应比 Gzip 小 15%–25%
- 执行
nginx -t && nginx -s reload，确认无报错；若提示unknown directive "brotli"，说明模块未编译进内核，brotli_comp_level根本不识别
