双压缩是为兼顾现代压缩率与旧浏览器兼容性：Brotli对文本压缩率高15%~20%且CPU开销低，但IE等不支持；Gzip则全兼容。二者非叠加而是按客户端Accept-Encoding智能分发，实现零感知兜底。
直接启用 Brotli + Gzip 双压缩架构，不是叠加使用，而是按客户端能力智能分发——现代浏览器优先走 Brotli（压缩率比 Gzip 高 15%~20%），老浏览器自动回退到 Gzip。这样既不牺牲兼容性，又能把出站带宽再压低一截。
为什么需要双压缩，而不是只开一个？
Brotli 是 Google 主导的现代压缩算法，对 HTML/CSS/JS 等文本资源压缩更狠，尤其在中高阶压缩级别（Brotli 的 q=11 相当于 Gzip level=9，但 CPU 开销更低）。但它的硬伤是：IE、旧版 Safari、部分安卓 WebView 不支持 Accept-Encoding: br。Gzip 则是 HTTP/1.1 以来的通用标准，所有浏览器都认。所以双压缩的本质是“兜底策略”：有 Brotli 就用，没有就切 Gzip，服务器零感知。
Brotli 静态预压缩 + Gzip 动态兜底（推荐生产组合）
别让 Nginx 在每次请求时实时压缩。真实压测表明：动态 Brotli（brotli on）在高并发下 CPU 暴涨，而预压缩 + brotli_static on 几乎不耗 CPU，还能提升首字节时间（TTFB）。
- 提前用
brotili命令行工具为所有静态文件生成.br副本，例如：find ./dist -type f \( -name "*.html" -o -name "*.js" -o -name "*.css" \) -exec brotli --quality=11 --output={}.br {} \; - Nginx 配置启用预压缩和回退逻辑：
brotli on;<br>brotli_static on;<br>brotli_types text/plain text/css application/javascript application/json application/xml image/svg+xml;<br>gzip on;<br>gzip_static on;<br>gzip_types text/plain text/css application/javascript application/json application/xml image/svg+xml;<br>gzip_vary on;
- 注意：
brotli_static on和gzip_static on都要求对应文件（如main.js.br或main.js.gz）真实存在，否则会跳过并尝试动态压缩（或直接不压）
关键兼容性与响应头控制
光配对指令不够，必须确保响应头精准反映实际编码方式，否则 CDN 或代理可能缓存错版本：
-
gzip_vary on和brotli_vary on必须同时开启，强制 Nginx 返回Vary: Accept-Encoding，让中间层知道该按客户端能力区分缓存 - 禁用对已知有问题客户端的 Brotli：
brotli_disable "msie6";<br>brotli_disable "msie"; # IE 全系不支持 Brotli
- 避免与 Gzip 冲突：Brotli 模块和 Gzip 模块互不干扰，但不要在同一个 location 块里对同一资源重复启用动态压缩（即不写
brotli on+gzip on同时生效；应靠_static指令驱动）
验证是否真正生效
别只看 Network 面板里有没有 Content-Encoding，要分三步确认：
- 用 Chrome 访问，打开 DevTools → Network → 刷新页面 → 点击任意 JS/CSS 文件 → 查看 Response Headers 中是否含
Content-Encoding: br - 用 Firefox 或旧版 Edge 访问同页面 → 应看到
Content-Encoding: gzip - curl 模拟不同请求头：
curl -H "Accept-Encoding: br" -I https://yoursite.com/app.js→ 应返回brcurl -H "Accept-Encoding: gzip" -I https://yoursite.com/app.js→ 应返回gzip
