brotli 是需构建、服务端、协议三层协同的压缩升级方案，比 gzip 多压15–20%；构建阶段预生成.br文件，服务端nginx启用ngx_brotli模块并设brotli_static always，协议层须https才能触发。
Brotli 不是简单替换 Gzip 的“开关”，而是需要构建、服务端、协议三层协同的压缩升级方案。它在相同资源下通常能比 Gzip 多压 15–20%，但前提是浏览器能拿到 .br 文件、服务端能稳定返回、且整个链路符合安全要求。
构建阶段：预生成 .br 文件，避免运行时开销
不推荐在请求时实时压缩，那样会增加服务器 CPU 压力并拖慢响应。正确做法是在打包阶段就产出 .br 文件：
- Vite 项目可使用 vite-plugin-compression，配置
algorithm: 'brotliCompress'和ext: '.br' - Webpack 可用 compression-webpack-plugin，设置
algorithm: 'brotliCompress' - 确保
threshold合理（如 ≥1KB），避免对极小文件无效压缩 - 打包后 dist 目录应同时存在
main.js和main.js.br
服务端阶段：Nginx 优先读 .br 文件，保留 gzip 兜底
Nginx 需要通过 ngx_brotli 模块支持，不能仅靠 rewrite 或 add_header 模拟：
- 确认已编译或安装该模块（宝塔用户可在“自定义模块”中勾选）
- 在 http 块中启用：
brotli on;+brotli_static always;（关键：优先查 .br 文件） - 指定压缩类型：
brotli_types text/css application/javascript ...，覆盖常见文本资源 - 务必保留原有
gzip on配置——老旧浏览器或 HTTP 环境自动降级到 gzip
协议与兼容性：HTTPS 是硬性前提
浏览器只在 HTTPS 下主动发送 Accept-Encoding: br 请求头。HTTP 环境中即使服务端支持，也不会触发 Brotli 传输：
- 检查站点是否强制跳转 HTTPS（301 或 HSTS）
- 用 Chrome DevTools 的 Network 面板，查看 JS/CSS 请求的 Response Headers 中是否有
content-encoding: br - 若看到
content-encoding: gzip，先排查是否走的是 HTTP，或 Nginx 未命中 .br 文件（如路径不对、权限不足）
进阶提示：压缩等级与文件类型匹配
Brotli 支持 0–11 级压缩，不是越高越好：
- 静态资源（JS/CSS/HTML）：建议设为 8–11，构建时多花几秒换来更小体积
- 动态接口返回（如 API JSON）：不建议运行时 Brotli 压缩，优先用 gzip 或关闭压缩
- 小文件（
