确认浏览器和服务器是否真正支持br编码需检查response headers中content-encoding: br是否存在，否则链路中断；nginx需配置brotli_static always、显式brotli_types及add_header vary "accept-encoding" always。
确认浏览器和服务器是否真正支持 br 编码
不是所有“标称支持 Brotli”的环境都能正确交付 .br 文件。常见错误是：Nginx 配置了 brotli on，但没启用 brotli_static always，导致预压缩的 bootstrap.min.css.br 被忽略，仍返回未压缩的 CSS；或 CDN（如 Cloudflare）虽支持 Brotli，但源站响应头没带 Vary: Accept-Encoding，造成缓存污染，用户拿到 gzip 版本却误以为是 br。
验证方法很简单：打开浏览器 DevTools → Network 标签页 → 刷新页面 → 找到任意 CSS 文件 → 查看 Response Headers 中是否有 Content-Encoding: br。如果没有，说明请求没走 Brotli 流程，别急着调参数，先查链路哪一环断了。
Nginx 启用 Brotli 的最小可行配置
官方 ngx_brotli 模块不内置，需编译时添加，但大多数云服务商（如腾讯云、阿里云托管型 Nginx）已预装。若自行部署，确认模块存在：nginx -V 2>&1 | grep -o with-brotli。配置本身很轻量：
http {
brotli on;
brotli_comp_level 6;
brotli_types text/css application/javascript image/svg+xml;
brotli_static always; # 关键：优先服务已存在的 .br 文件
}
注意三点：
• brotli_static always 比 on 更激进，它会直接返回同名 .br 文件（哪怕原始文件更新了也没关系，只要构建流程保证 .br 同步更新）；
• brotli_comp_level 推荐设为 6–8：等级 11 压缩 JS/CSS 效果提升微弱，但 CPU 占用翻倍，对高并发静态资源服务不划算；
• brotli_types 务必显式列出 text/css，否则默认不压缩 CSS。
Webpack 构建时预生成 .br 文件而非运行时压缩
运行时压缩（如 compression-webpack-plugin 配 algorithm: 'brotliCompress'）只在开发服务器生效，生产环境仍依赖服务器配置。真正在构建阶段产出 bootstrap.min.css.br 才能确保 CDN 或 Nginx 直接投递，避免动态压缩开销。
推荐做法是用命令行工具预压缩：
- 安装：
npm install --save-dev brotli或直接用系统级brotli命令（macOSbrew install brotli，Ubuntuapt install brotli） - 脚本示例：
brotli -q 11 -f -o dist/bootstrap.min.css.br dist/bootstrap.min.css - 关键参数：
-q 11对 CSS 这类文本资源值得拉满；-f强制覆盖；-o显式指定输出路径，避免隐式重命名
构建后务必检查输出目录是否存在 .br 文件，且大小明显小于原文件（通常小 20%+）。漏掉这步，Nginx 的 brotli_static 就是空转。
CDN 场景下必须补全 Vary: Accept-Encoding
这是最容易被忽略的兼容性开关。如果用了 CDN（如 jsDelivr、Cloudflare、又拍云），即使源站返回了 Content-Encoding: br，CDN 若未透传或未设置 Vary 头，就可能把 br 版本缓存下来，然后错误地返回给只支持 gzip 的旧客户端（比如某些企业内网 IE11）。
解决方式分两层：
• 源站 Nginx 配置里加：add_header Vary "Accept-Encoding" always;（always 确保 304 响应也带）
• CDN 控制台检查「缓存规则」是否允许 Vary 头参与缓存键计算（Cloudflare 叫 “Cache key customization”，默认开启；又拍云需勾选“根据请求头缓存”并填入 Accept-Encoding）
没这句，Brotli 压缩再好，也可能让部分用户加载失败或降级失效——因为缓存系统根本不知道该按什么维度区分版本。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
