brotli压缩cpu影响需实测：动态内容以level 4为基准压测ttfb与cpu占用，关注level 4→5时ttfb升>8%、cpu跳升>40%的拐点；静态资源应预压缩至level 6/7，运行时零开销；必配brotli_min_length 1024等参数防负优化，并通过日志与监控验证效果。
评估 Brotli 压缩对 CPU 的实际影响，不能只看配置等级，而要结合资源类型、请求频率、并发压力和响应体特征来实测判断。最优配比不是固定值，而是让“每 1% 体积节省”所增加的 CPU 时间尽可能低。
动态内容：用 level 4 为基准做压测对比
API 返回、PHP/Node 渲染的 HTML、实时 JSON 等，特点是每次请求都需实时压缩，CPU 开销直接反映在首字节时间（TTFB）和 CPU 使用率曲线上。
- 先固定 brotli_comp_level 4，用 wrk 或 ab 模拟 50–200 QPS，记录平均 TTFB 和 top 中 nginx worker 的 CPU 占用率
- 再分别切到 level 3 和 level 5，保持其他参数（brotli_min_length、brotli_window）不变，重复压测
- 重点观察：level 4 → 5 时，TTFB 是否上升 >8%，CPU 占用是否跳升 >40%；若体积仅少 1.2KB 但延迟明显变高，说明已越过收益拐点
静态资源：不压运行时，只压构建阶段
CSS、JS、HTML 等构建产出文件，真正高效的做法是预压缩（build-time），而非运行时计算。此时 CPU 负载几乎为零，level 设高也无代价。
- 前端打包时用 CompressionWebpackPlugin 或 rollup-plugin-brotli 生成 .br 文件，level 设为 6 或 7
- Nginx 配置 brotli_static always，并确保 brotli on 和 brotli_static on 同时启用（注意：不是 brotli_static off）
- 验证方式：curl -I -H "Accept-Encoding: br" 请求一个 JS，响应头应含 Content-Encoding: br，且响应体大小比未压缩时小 20% 左右，但 nginx worker CPU 无明显波动
关键约束参数必须同步调优
只调 brotli_comp_level 不够，若没限制作用范围，小响应也会被压缩，反而拉高无效 CPU 开销。
- brotli_min_length 1024：跳过小于 1KB 的响应（如空 JSON、短错误提示），避免负优化
- brotli_buffers 16 8k：匹配常见文本块大小，减少内存重分配次数
- brotli_window 1m：对模板类 HTML 或长 JS bundle 有效，增大窗口可提升长距离重复匹配率，但对小文件无意义，慎开
真实环境验证要点
配置上线后，靠日志和监控交叉验证，而不是只信 curl 结果。
- 检查 access log 中 $request_time 和 $upstream_response_time 差值，若差值持续 >15ms，说明压缩耗时已成瓶颈
- 用 pidstat -p $(pgrep nginx) 1 观察 worker 进程的 %CPU，高峰时段超过 70% 就需回退 level
- 对比同一资源开启 Brotli 前后的体积：典型 JS 从 124KB → 92KB（-25%），若只降到 118KB（-5%），说明可能没生效或被 gzip 覆盖
