Brotli压缩级别需分层配置：动态内容用2–4级保响应，构建产物用6级平衡，长期静态资源用8–11级加预压缩；须验证模块启用、禁用brotli_static于动态场景、精准设置brotli_types并保留gzip后备。

别把 brotli_comp_level 当成“越高越好”的开关——它本质是压缩率和 CPU 开销的权衡刻度。在生产环境真正起效，关键在于按资源生命周期、生成方式和访问特征分层设值，而不是全局统一写个 11。

动态内容：限级保响应，1–4 是安全区间

API 接口返回的 JSON、服务端渲染的 HTML、PHP/Node 生成的实时页面，都属于“每次请求都重算”的动态内容。这类内容若用高阶压缩，会直接拖慢首字节时间（TTFB），尤其在高并发下易引发 P95 延迟跳升。

• 实测显示：brotli_comp_level 3 对 JSON 的压缩率已稳定高于 Gzip level 9，而单次压缩耗时降低约 60%
• 建议将 location /api/ 或 location ~ \.php$ 块中显式设为 brotli_comp_level 2–4
• 务必配合 brotli_min_length 20，避免对空响应或极小报文（如 {"ok":true}）做无效压缩

前端构建产物：平衡点在 level 6

Vite/webpack 打包输出的 app-xxx.js、chunk-vendors.css 等文件，特点是体积大、内容稳定、但非完全静态（哈希值随构建变化）。它们适合中等强度实时压缩。

• brotli_comp_level 6 是实测最优平衡点：压缩率约 65%，TTFB 增加可控（+1–3ms），CPU 占用温和
• 不推荐预压缩（brotli_static on）这类文件，因哈希路径频繁变更，容易产生大量未被命中的 .br 文件，反而浪费磁盘与维护成本
• 确保 brotli_types 包含 application/javascript 和 text/css，不要写过时的 text/javascript

长期静态资源：大胆用 8–11 + brotli_static on

logo.svg、reset.css、字体文件（woff2）、第三方库 CDN 本地缓存副本等，更新频率极低（数月甚至数年不变），且体积适中（几 KB 到几百 KB）。这类资源最适合高压缩级别 + 预压缩组合。

• 在构建阶段用 vite-plugin-compression 或 compression-webpack-plugin 生成 .br 文件，算法指定 brotliCompress
• Nginx 中启用 brotli_static on，并确认文件权限为 644 或 755，属主与 worker 进程一致（如 www-data）
• 此时 brotli_comp_level 可设为 8–11，因为压缩只发生一次，运行时零 CPU 开销

避坑要点：这些配置不写等于白调

再合理的 brotli_comp_level，如果基础配置没闭环，照样不生效。

• 必须验证模块已集成：nginx -V 2>&1 | grep with-http_brotli_module，无输出说明编译失败
• 动态压缩场景下，brotli_static 必须为 off；否则 Nginx 会跳过实时压缩，只查 .br 文件，查不到就裸发
• brotli_types 要精准，剔除 image/png、font/woff2、application/pdf 等已压缩格式，否则徒增 CPU 负担
• 保留 Gzip 作为后备：gzip on 和 brotli on 可共存，Nginx 会按客户端 Accept-Encoding 自动协商，现代浏览器优先选 br