启用Brotli+Gzip双压缩需基于HTTP协商自适应：优先Brotli，自动回退Gzip；按MIME类型精准压缩文本类资源，禁压已压缩二进制格式；设最小长度1KB、Gzip级6、Brotli级7–9；构建预压缩优于运行时压缩，避免与SRI或HTML优化冲突。
直接启用 Brotli + Gzip 双压缩不是简单“两个都开”，而是建立一套有优先级、有边界、有兜底的自适应策略：现代浏览器用 Brotli 获取更小体积，老旧环境自动回退到 Gzip 保证可用，全程无需 UA 判断，靠标准 HTTP 协商机制驱动。
只压该压的文件类型
压缩不是越全越好，无效压缩反而浪费 CPU、拖慢响应。必须严格按 MIME 类型控制范围：
- 必须压缩：text/plain、text/css、application/javascript、application/json、text/xml、application/xml、image/svg+xml
- 谨慎可选：application/rss+xml、image/tiff（极少见，确认未压缩再启用）
- 绝对禁压：.jpg/.jpeg/.png/.gif/.webp/.mp4/.webm/.pdf/.woff2 等所有已压缩二进制格式——它们再套 Brotli 或 Gzip 不仅体积几乎不减，还会抬高服务器负载，甚至引发校验失败
设好阈值与压缩级别
小文件不值得压，高压缩级不等于高收益。关键参数要匹配实际场景：
- 最小压缩长度设为 1024 字节（1KB）：避免对空响应、短内联脚本等做无意义压缩
- Gzip 级别用 6：实测压缩率约 65%，CPU 占用增幅可控（15%–20%），比级别 9 更具性价比
- Brotli 级别推荐 7–9：Brotli 在 7 级时已超越 Gzip 9 级的压缩效果，且耗时明显低于 11 级；构建时预压缩可用 9 级，运行时动态压缩建议 7 级
让 Brotli 优先、Gzip 自动兜底
浏览器通过 Accept-Encoding 请求头声明支持能力，服务端应完全依赖该标准，而非手动解析 User-Agent：
- 当请求头含 br, gzip（如 Chrome/Firefox/Edge/Safari 16.4+），服务端优先返回 Content-Encoding: br
- 当只含 gzip（如 IE、旧版 Android WebView），自动回落到 Gzip 响应
- Nginx 中启用 brotli_static on，并提前生成 .br 文件，可跳过运行时压缩，大幅提升首字节时间
- 确保源站统一管控压缩逻辑，若 CDN 或网关层已压缩，后端需关闭重复压缩，避免 Content-Encoding 冲突或校验失效
注意构建与运行时的分工
压缩策略要区分阶段，避免资源浪费和兼容风险：
- 构建时预压缩：用 brotli --quality=9 --output=main.js.br main.js 生成 .br 和 .gz 文件，静态托管场景下最高效
- 运行时动态压缩：适用于 SSR 或内容频繁变更的服务，但需限制 Brotli 启用范围（如仅限 HTML/CSS/JS），并监控 CPU 使用率
- 若前端存在资源完整性校验（如 SRI hash），必须关闭服务端压缩，否则解压后内容与哈希不匹配，导致加载失败
- HTML 自动去空格、CSS 内联等优化功能，与服务端压缩互斥——二者同时开启时，压缩会覆盖优化结果，建议只保留其一
