Brotli加速API响应需聚焦动态压缩：在location /api/中启用brotli on、禁用brotli_static、限定types、设level 4；预压缩模板用brotli_static always；反向代理需透传Accept-Encoding并更新cache_key；三处验证Content-Encoding: br生效。
API 接口响应的 Brotli 加速，核心不是“让状态码更快”，而是让 JSON 响应体更小、传输更快、解压更轻——这三步直接影响移动端首屏渲染和错误反馈速度。
精准启用动态压缩（针对 /api/ 路径）
别在全局 http 块盲目开 brotli on，要聚焦接口路径。在 location /api/ 中明确配置：
- brotli on; —— 启用实时压缩，服务端对每个响应体做即时编码
- brotli_static off; —— 关键！设为 on 会跳过动态压缩，只查 .br 文件，而 API 响应是动态生成的
- brotli_types application/json text/plain; —— 只压缩实际类型，避免误压二进制或空响应
- brotli_comp_level 4; —— 实测最优：比 gzip 再省 12–18% 体积，解压耗时 ≤3ms（iOS/Android 主流机型）
预压缩通用响应模板（提升 TTFB）
对固定结构的错误码、空响应等高频模板，提前生成 .br 文件，绕过运行时 CPU 开销：
- 用
brotli -q 4 --gzip-fallback error-500.json生成error-500.json.br - Nginx 配置 brotli_static always;（注意是 always，非 on）
- 确保文件权限可读，Nginx worker 进程能访问；否则静默失效，无日志报错
确保协商链路完整（浏览器 → Nginx → 后端）
如果 Nginx 是反向代理，仅压缩发给前端的响应还不够，回源环节也要带 Brotli 能力：
- 在
location /api/中加：proxy_set_header Accept-Encoding "br,gzip,deflate";（br 放最前） - 后端服务（如 Node.js 或另一台 Nginx）必须支持并返回
Content-Encoding: br - 缓存键加入编码标识：proxy_cache_key "$scheme$request_method$host$request_uri$http_accept_encoding";，防止 br/gzip 版本混用
验证是否真正生效
不能只看 Network 面板 Size 小，要确认三处：
- 响应头含 Content-Encoding: br，且 Content-Length 明显小于原始 JSON
- curl 直连后端：
curl -H "Accept-Encoding: br" -I https://backend/api/user，看是否返回 br - 边缘 Nginx access log 中添加
$upstream_http_content_encoding字段，确认上游返回的是 br
