Brotli压缩应在压缩率、CPU开销与响应可预期性间求平衡，采用静态预压缩为主、动态压缩为辅、HTTPS下精准协商、关键参数严控阈值的策略。
在生产环境中，Brotli 压缩不是压得越狠越好，而是要在压缩率、CPU 开销和响应可预期性之间找一个稳定支点。核心思路是：静态预压缩为主、动态压缩为辅、HTTPS 下精准协商、关键参数严控阈值。
构建阶段用预压缩替代运行时压缩
避免 Nginx 在请求高峰期实时调用 brotli_compress —— 这会把 CPU 压力直接暴露在高并发链路上。正确做法是在构建环节（如 Vite、Webpack）生成 .br 文件：
- 配置插件（如
vite-plugin-compression）启用algorithm: 'brotliCompress'，设置threshold: 1024（≥1KB 才压缩） - 产出文件如
index.js和index.js.br并存于 dist 目录 - Nginx 启用
brotli_static on，优先读取已存在的 .br 文件，毫秒级返回，零 CPU 消耗
Nginx 动态压缩只做兜底，不作主力
当预压缩文件缺失（如临时上传的 HTML 或 API 返回体），才启用动态压缩。此时必须限制其“出力范围”，防止拖慢整体响应：
-
brotli_comp_level 4–6：Level 11 压缩率仅比 Level 6 高约 3%～5%，但 CPU 时间可能翻倍；实测 Level 6 在文本资源上已达增益上限的 92% -
brotli_min_length 1000：过滤掉小响应（如空 JSON、短错误提示），避免大量微小请求反复触发压缩流程 -
brotli_types显式限定：只写text/html application/javascript text/css application/json image/svg+xml，不包含font/woff2或image/*等已压缩类型
强制 HTTPS + 内容协商机制保障交付可靠性
Brotli 只在 HTTPS 下生效，这是浏览器策略，不是配置可绕过：
- 确认站点全站跳转 HTTPS（301 或 HSTS），否则 Chrome/Firefox 不会发送
Accept-Encoding: br - Nginx 中保留
gzip on并精简gzip_types text/plain，作为极窄兜底（仅服务明确不支持 br 的老旧环境） - 禁用全局
gzip后再启用brotli，或确保gzip_types与brotli_types完全无交集，避免协商冲突
验证是否真平衡：看日志，不只看 Header
别只检查单个请求的 Content-Encoding: br，要关注高并发下的分布稳定性：
- 在 Nginx access log 中加入
$sent_http_content_encoding字段，采样高峰期日志，统计br / gzip / –占比 - 若
–（未压缩）占比超 5%，说明brotli_min_length或brotli_types漏掉了本该压的资源 - 用
curl -H "Accept-Encoding: br" -I对比同一 JS 文件的Content-Length：Brotli 应比 Gzip 小 15%～22%，且 TTFB 波动控制在 ±10ms 内
