Nginx Brotli 最小体积需分层设等级并调优参数：静态资源用预压缩+level 6–8（推荐7），动态内容选level 3–5（推荐4）；必配brotli_window 1m、brotli_min_length 1024、精准brotli_types；实测验证Content-Encoding: br及体积降幅。
要让 Nginx 的 Brotli 压缩真正压出最小体积，不能只设 brotli_comp_level 11。实际中，压缩质量需按资源类型分层设定，并配合窗口、字典、预压缩等关键参数协同生效。
静态资源用预压缩 + 高等级（6–8）
前端构建产物（如 app.js、style.css）适合离线压到极致，因为不消耗运行时 CPU：
- 构建阶段用
vite-plugin-compression或compression-webpack-plugin，指定algorithm: 'brotliCompress'和level: 7 - Nginx 开启
brotli_static on，它只查同名.br文件，不参与计算 - 实测 level 7 比 level 6 体积再降约 1.2–1.8%，level 8 起收益趋近于零，但构建时间明显上升
动态内容选中等级（3–5），避免盲目拉高
PHP 渲染页、API 返回的 JSON、实时生成的 HTML 属于高频低缓存资源，压缩发生在每次响应时：
- 设
brotli_comp_level 4是通用平衡点：比 Gzip level 6 体积小约 18%，Nginx 编码耗时可控 - 设为 5 是上限——再往上（如 6+），CPU 时间可能翻倍，但体积仅多减不到 2%
- 对延迟敏感接口（如首屏 HTML），可用 level 3：压缩率接近 Gzip level 6，TTFB 更稳
必须调优的辅助参数
只改 comp_level 不够，以下三项直接影响最终体积：
-
brotli_window 1m：增大滑动窗口，提升长距离重复匹配效率，对含大量 class/id 的 HTML 特别有效 -
brotli_min_length 1024：小于 1KB 的响应跳过压缩，避免小 JSON（如{}）白耗 CPU - 确保
brotli_types精准覆盖：至少包含text/html application/javascript text/css application/json image/svg+xml，不加图片/字体等已压缩格式
验证是否真压得更小
配置不是终点，要实测体积变化：
- 用
curl -I -H "Accept-Encoding: br" https://yoursite.com/main.js确认响应头含Content-Encoding: br - 对比同一文件开启前后的大小：JS/CSS 通常从 124KB → 92KB 左右，压缩率应比 Gzip 高 17–25%
- 若体积没明显下降，优先检查
nginx -V是否含with-http_brotli_module，以及brotli_static是否误开导致跳过动态压缩
