大型项目Brotli部署需分层分区精细化控制：构建预压缩为主（CI/CD生成.br/.gz）、动态压缩为辅（API限类型低等级）、双编码兜底、缓存键含Accept-Encoding隔离。
大型项目部署 Brotli 不能靠“全局开个 brotli on”就完事，必须分层、分区、分资源做精细化控制。核心是：构建预压缩为主、动态压缩为辅、双编码兜底、缓存键精准隔离。
静态资源走预压缩 + brotli_static on
前端构建产物（如 dist/ 下的 JS/CSS/HTML/SVG）全部在 CI/CD 阶段用 brotli --quality=6-8 生成 .br 文件。Nginx 配置中启用：
-
brotli_static on;—— 直接返回已存在的.br文件，零 CPU 开销 -
brotli_types text/css application/javascript text/html image/svg+xml;—— 不扩大范围，避免对图片、字体等二进制文件无效尝试 - 确保构建脚本同步生成
.gz文件，并配gzip_static on;，为不支持br的客户端留退路
API 和动态内容用轻量级动态压缩
后端接口（如 /api/、/graphql）无法预压缩，需开启低开销动态压缩：
- 在对应
location块中单独配置：brotli on; brotli_comp_level 4; brotli_min_length 512; - 只对
application/json、text/plain启用，禁用image/、video/等类型 - 搭配
brotli_vary on;，强制响应头带Vary: Accept-Encoding，防止 CDN 缓存错版本
边缘网关层做 Accept-Encoding 路由与缓存隔离
若使用 Nginx 作边缘代理（如前置 CDN 或多级网关），必须保障请求链路不“串码”：
- 回源时固定携带：
proxy_set_header Accept-Encoding "br,gzip,deflate";，且br排首位 - 缓存 key 必须含编码标识：
proxy_cache_key "$scheme$request_method$host$request_uri$http_accept_encoding"; - 对明确不支持 br 的 UA（如
MSIE、Trident、WebView/3.*），用map规则清空$http_accept_encoding，强制走 gzip 回源
构建与运维协同闭环
单靠 Nginx 配置无法落地，需前后端、CI/CD、SRE 共同约定规范：
- Webpack/Vite 插件统一启用
compression-webpack-plugin或vite-plugin-compression，输出.br和.gz - 发布检查清单包含：
find dist -name "*.js.br" | head -1是否非空、nginx -t是否通过、curl -I -H "Accept-Encoding: br" https://yoursite.com/app.js返回Content-Encoding: br - 监控项加入：
brotli_ratio（br 响应占比）、brotli_cpu_usage（动态压缩模块 CPU 占比），异常时自动告警
