关键在于明确Brotli非Gzip替代品，而是需HTTPS前提、模块就位、精准types配置、预压缩优先、brotli_static always启用，并关闭gzip_static以避免冲突。
要让 Nginx 对静态资源真正实现高效压缩，关键不是堆参数，而是理清 Gzip 和 Brotli 的分工逻辑、生效条件与典型陷阱。Brotli 不是 Gzip 的升级开关，而是一个需主动引入、有协议限制、讲策略配置的增强选项。
确认 Brotli 模块是否就位
所有 brotli 配置的前提是模块已加载。运行 nginx -V 2>&1 | grep -o ngx_brotli，有输出才说明可用。没输出就别写任何 brotli 指令——它不会报错，但完全不生效。
- Ubuntu/Debian 用户可直接安装 nginx-extras（含内置 Brotli 支持）
- CentOS/RHEL 或自编译用户，需手动集成 google/ngx_brotli 模块，并确保系统已装 brotli-devel
- Docker 环境推荐使用 tiangolo/nginx-brotli 等预装镜像
Brotli 必须走 HTTPS，且不能和 Gzip 混乱协商
Brotli 只对 HTTPS 请求响应 br 编码。HTTP 下浏览器通常不发 Accept-Encoding: br，Nginx 就不会启用它。这不是 bug，是设计行为。
-
brotli on 必须放在
http{}块顶层，且紧随其后写 gzip off（最稳妥）或大幅精简gzip_types（仅留 text/plain 等极少数兜底类型） - 不要用
gzip_disable、gzip_vary off等干扰协商的指令，它们可能破坏 br/gzip 的自动选择逻辑 - 现代浏览器默认按
br,gzip优先级发起请求，只要 Brotli 模块就位、HTTPS 可用、MIME 匹配，就会稳定返回Content-Encoding: br
按资源类型设压缩级别与阈值
统一设 brotli_comp_level 11 是常见误操作。CPU 开销陡增，体积收益却微乎其微。
- 静态 JS/CSS/HTML：推荐 6–7（构建时可打到 11，运行时不必）
- 动态 API 响应（JSON/XML）：建议 3–5，降低延迟敏感型接口的首字节时间
- 必须设 brotli_min_length 1024（1KB），过滤掉小响应（如空 JSON、短错误提示），避免无谓 CPU 消耗
-
brotli_types要精准：包含text/html text/css application/javascript application/json image/svg+xml；排除image/png font/woff2 application/pdf等已压缩格式
静态文件优先用预压缩 + brotli_static
对构建产出的 JS/CSS/HTML，运行时动态压缩是低效选择。应提前生成 .br 文件，由 Nginx 直接提供。
- 构建阶段批量生成：
find ./dist -name "*.js" -exec brotli -q 6 -k {} \;（-k保留原始时间戳，利于缓存校验） - Nginx 中启用 brotli_static always：强制查找同名 .br 文件，找不到才 fallback 到动态压缩
- 务必检查 .br 文件权限，确保 Nginx worker 进程可读，否则静默返回未压缩内容
- 若同时启用了
gzip_static on，请关闭它——否则当app.js.gz存在时，Nginx 可能跳过 Brotli 直接发 gzip 版
验证是否真实生效
别只看配置写了没，要实测响应头。
- 命令行验证：
curl -H "Accept-Encoding: br,gzip" -I https://yoursite.com/main.js，确认返回头含Content-Encoding: br - 浏览器验证：打开 DevTools → Network → 点开资源 → Headers → Response Headers，直接查看
Content-Encoding字段 - 若返回
gzip：先确认请求走的是 HTTPS；再查brotli_types是否包含该资源 MIME 类型；最后检查文件大小是否低于brotli_min_length
