brotli 本身不必然导致 cpu 过载，关键在配置失当：高频小响应、大体积动态响应、高压缩级别滥用三类行为会使其成为“cpu 放大器”；应结合日志分析、降级验证与预压缩优化。
评估高并发下 Brotli 对 CPU 的额外占用，关键不是看“开了 Brotli 之后 CPU 升了多少”，而是看压缩行为是否在错误时机、对错误资源、以错误强度被触发。Brotli 本身不必然导致 CPU 过载，但配置失当会让它在流量高峰时变成“CPU 放大器”。
盯住三类高危压缩行为
真正吃 CPU 的从来不是 Brotli 算法本身，而是它被反复、低效、无差别调用的过程：
- 高频小响应压缩：brotli_min_length 过低（如默认 20 字节），导致大量 API 空响应、短 JSON、304 响应反复进压缩流程，徒增事件循环负担
- 大体积动态响应压缩：brotli_types 包含 application/json 或 text/html，而上游返回未分块的 3MB+ HTML/JSON，Brotli 会全量缓冲再压，内存+CPU 双飙升
- 高压缩级别滥用：brotli_comp_level 设为 9 或 11，实测 Level 6 到 Level 11 的 CPU 耗时常呈指数增长，但体积仅多减 2%–3%
用真实请求特征反推 CPU 压力源
别只看 top 里 nginx worker 的 %CPU，要结合 access log 和 error log 找出“谁在拖慢整体”：
- 在 access log 中加入
$sent_http_content_encoding $request_time $body_bytes_sent $http_user_agent字段，采样高峰期数据 - 筛选出 content-encoding: br 且
$body_bytes_sent > 500000（500KB+）或$request_time > 0.5（500ms+）的请求，它们大概率是 CPU 热点 - 同步检查 error.log 是否出现
pool alloc频繁记录、worker process X exited on signal 9或 upstream timeout —— 这些是内存和 CPU 同时承压的信号
做一次轻量级降级验证
这是归因最直接的方法，无需改代码或重编译：
- 临时注释掉所有 brotli_* 指令（保留 gzip off），reload Nginx
- 观察 5–10 分钟内 CPU 使用率变化（建议用 htop 看单个 worker 进程，而非整体平均）
- 若 CPU 显著回落（如从 85% → 45%），且 TTFB 下降明显，说明 Brotli 配置确为瓶颈；若变化微弱，则问题可能在 rewrite、SSL 握手或后端延迟
用预压缩替代动态压缩来卸载 CPU
对 JS/CSS/HTML/SVG 等静态资源，完全可绕过运行时压缩：
- 构建阶段用
brotli -Z -f --quality=11 asset.js生成asset.js.br - Nginx 开启
brotli_static on;，并确保brotli on;仍启用（兜底用） - 此时 Brotli 不再消耗 CPU，仅多一次文件存在性判断（stat 系统调用），开销可忽略
