调优 brotli_comp_level 的核心是平衡压缩收益与运行时开销，需按资源类型分层设置：动态内容限 1–4 级，构建产物推荐 6 级，API 接口禁用 8+ 级；须验证模块编译与响应头，并以 gzip 为兜底、location 精细控制、监控 ratio 与延迟。
调优 brotli_comp_level 的核心目标，是让压缩收益（带宽节省）与运行时开销（CPU 占用、TTFB 延迟）取得实际可测的平衡。它不是“设得越高越好”，而是按内容生成方式和访问特征分层控制。
区分三类资源，对应不同压缩级别
动态内容（如 PHP 渲染页、Node.js 接口返回的 HTML/JSON）：必须限制在 1–4 级。实测 level 4 比 Gzip 9 级压缩率更高，但单次编码耗时降低约 60%，P95 TTFB 更稳定。设为 8+ 会导致高并发下 worker 进程 CPU 持续过载，首字节延迟明显上浮。
前端构建产物（如 app-xxx.js、main.css、vendor.chunk.js）：推荐 level 6。该级别在 V8 引擎常见 JS 体积下压缩率约 65%，TTFB 增加可控（通常
长期不变的静态资源（如 logo.svg、reset.css、font.woff2 的文本替代 CSS）：可设 8–11，但前提是启用 brotli_static on 并已预生成 .br 文件。此时压缩完全发生在构建阶段，Nginx 不做任何实时计算，对时延零影响。
避免盲目设 11 的真实代价
在 QPS > 500 的 API 网关场景中，将 brotli_comp_level 11 应用于 JSON 接口，单次响应平均多耗 25–30ms CPU 时间，P95 延迟跳升 12% 以上。这不是理论值，而是 Nginx worker 日志中 upstream_response_time 的可观测增长。
level 11 对小文件（brotli_min_length 1024 屏蔽无效压缩。
若未预生成 .br 文件而误配 brotli_static on，Nginx 将直接跳过压缩逻辑，既不 fallback 到动态压缩，也不报错——结果是用户收不到 br 编码，但你还在为没发生的压缩付出配置维护成本。
配置落地前必须验证的两件事
执行 nginx -V 2>&1 | grep with-http_brotli_module，确认模块已编译进内核。没有这行输出，所有 brotli 指令都无效。
用 curl 测试真实响应头：curl -H "Accept-Encoding: br" -I https://yoursite.com/app.js，检查返回中是否含 Content-Encoding: br 和 Vary: Accept-Encoding。缺任一者，说明协商失败或配置未生效。
配套建议：用 gzip 做兜底，不依赖单一算法
保持 gzip on 开启，并设置合理 gzip_comp_level 4 和 gzip_types。Brotli 优先，Gzip 自动 fallback，浏览器兼容性无风险。
在 location 块中精细控制，例如只对 /api/ 启用 Brotli 动态压缩，其他路径走预压缩静态服务，避免全局一刀切。
监控 Nginx 的 gzip_ratio 和 brotli_ratio（需开启 stub_status）或通过日志分析 $sent_http_content_encoding 字段分布，持续观察不同 level 下的压缩率与延迟比值变化。
