brotli极致体积缩减关键在于预压缩优先、类型精准、开销可控：必须启用brotli_static always并确保.br文件存在，显式配置brotli_types覆盖text/css、application/javascript等关键mime，按资源类型分层设压缩等级（构建用11级，api响应用3–4级），配合brotli_vary on与精简gzip兜底。
要让 Brotli 在 Nginx 中真正实现极致体积缩减，关键不是盲目拉高压缩等级，而是构建一条“预压缩优先、类型精准、开销可控”的交付链路。动态压缩（即 on-the-fly）在生产环境应禁用，否则 CPU 会成为瓶颈，体积收益反而被延迟和稳定性拖垮。
必须启用预压缩并确保文件真实存在
启用 brotli_static always 是体积优化的起点。它强制 Nginx 直接返回已构建好的 .br 文件，零 CPU 开销、毫秒级响应。但前提是构建产物中必须有对应文件，例如 app.js.br 和 style.css.br。若缺失，Nginx 会静默跳过，不 fallback 到 gzip 或动态压缩。
- Vite 项目：配置
vite-plugin-compression，设algorithm: 'brotliCompress'，deleteOriginFile: false - Webpack 项目：用
compression-webpack-plugin，test: /\.(js|css|html|svg)$/，compressionOptions: { level: 11 } - 命令行补漏：对已有静态资源批量压缩，
brotli -q 11 -f -o dist/main.css.br dist/main.css
精细设置 brotli_types 并覆盖关键 MIME
Brotli 默认不压缩任何类型，必须显式声明。漏掉 application/javascript 或 image/svg+xml，JS 和 SVG 就不会被压——这是线上常见“配置了却没生效”的主因。
- 推荐清单：
text/plain text/css text/javascript application/javascript application/json application/xml image/svg+xml font/opentype - 避免泛写
text/*或application/*，可能误压二进制资源或触发安全拦截 - HTML 文件需单独确认：若使用
compression-webpack-plugin，务必在test正则中包含\.html$
压缩等级按资源类型分层设定
统一设 brotli_comp_level 11 是误区。高压缩比只对文本类资源有效，且等级 9–11 的 CPU 消耗呈非线性增长，TTFB 明显升高。
- CSS / JS / HTML：构建时用
-q 11（Webpack/Vite 插件中设level: 11），这类纯文本受益最大 - API 响应（JSON/XML）：Nginx 运行时压缩设为
brotli_comp_level 3–4，兼顾速度与体积 - 字体（woff2/ttf）和图片：不启用 Brotli，它们本身已是高压缩格式，再压无效甚至膨胀
配合 Vary 头与 Gzip 兜底防缓存污染
仅开启 Brotli 不够，CDN 或代理层若缓存未区分编码方式，用户可能拿到错版资源。必须靠 Vary: Accept-Encoding 确保缓存键唯一。
- Nginx 中加
brotli_vary on;和gzip_vary on;，两者共存不冲突 - Gzip 保留为兜底：设
gzip_types text/plain;即可，仅保障最基础文本兼容 IE11 等旧环境 - 验证方式：Chrome DevTools → Network → 任一 JS/CSS 文件 → Response Headers 查看是否含
Content-Encoding: br和Vary: Accept-Encoding
