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
