nginx生产环境启用brotli核心是构建可验证、可回退、低开销、高命中的压缩链路：必须编译集成ngx_brotli模块、系统级安装libbrotli、前端构建生成.br文件；配置上优先brotli_static on预压缩，配合gzip兜底，禁用动态压缩防cpu瓶颈。
Linux Nginx 生产环境启用 Brotli，核心不是“加个配置”，而是构建一条可验证、可回退、低开销、高命中的压缩链路。它必须与 Gzip 兜底协同，且优先走预压缩路径，而非依赖实时编码——否则高并发下 CPU 会成为瓶颈。
必须完成的三件基础事
缺一不可，否则后续所有优化都无效：
-
编译集成 ngx_brotli 模块：官方 Nginx 不含 Brotli，需源码编译时显式加入
--add-dynamic-module=../ngx_brotli；验证命令：nginx -V 2>&1 | grep with-http_brotli_module，有输出才算成功 -
系统级安装 libbrotli：用 autotools 编译安装到
/usr/local，并执行sudo ldconfig刷新动态库缓存，否则 Nginx 启动报 “symbol lookup error” -
前端构建阶段生成 .br 文件：如 Vite 项目配
vite-plugin-compression，Webpack 用compression-webpack-plugin，输出app.js.br、style.css.br等，Nginx 才能真正启用brotli_static on
推荐的生产级配置片段（放 http 块）
兼顾安全性、兼容性与性能，不追求极致压缩比，而重稳定交付：
brotli on; brotli_static on; # 关键：优先发预压缩文件，零 CPU 开销 brotli_types text/plain text/css application/javascript application/json application/xml image/svg+xml; brotli_comp_level 6; # 静态资源用 6；API 接口建议调至 3–4 brotli_min_length 1024; # 小于 1KB 不压，避免得不偿失 brotli_vary on; # 强制返回 Vary: Accept-Encoding，防 CDN 缓存错乱 <p>gzip on; gzip_static on; gzip_types text/plain text/css application/javascript application/json application/xml image/svg+xml; gzip_comp_level 6; gzip_vary on; gzip_min_length 1024;</p>
注意：brotli_static on 和 gzip_static on 必须对应存在真实文件（.br 和 .gz），否则 Nginx 会静默跳过，不会 fallback。
按资源类型分层调优
统一设 comp_level 11 是典型误区——它在高 QPS 场景下会显著拖慢 TTFB：
-
长期不变的静态资源（如打包后的 JS/CSS/HTML）：用
brotli_comp_level 7–8+ 构建时预压缩，压缩率可达 ~68%，传输节省明显 -
动态生成内容（PHP 渲染页、API JSON 响应）：设为
3–4，实测比 Gzip level 9 压缩率仍高 15%，但 CPU 耗时降低 50% 以上 -
SVG、XML、JSON 等结构化文本：Brotli 天然友好，可放宽
brotli_window 1m提升长距离重复识别能力
上线前必验的四个信号
配置生效 ≠ 实际生效，需逐项确认：
- 响应头含
Content-Encoding: br（Chrome DevTools → Network → Headers） - 响应体大小比未压缩时小 60%+（对比原始文件或
Content-Length） - 日志中无
open() "/xxx.js.br" failed (13: Permission denied)类权限错误 - 老浏览器（如 IE11）请求仍返回
Content-Encoding: gzip，且页面功能正常
