Brotli压缩不改变HTTP状态码及返回速度，真正影响移动端感知敏捷度的是API响应体的压缩传输与解压效率；应配置brotli_comp_level 4、启用brotli_static always预压缩、手动添加Vary头并关闭gzip冗余协商。
Brotli 压缩本身不改变 HTTP 状态码（如 200、404、500），也不直接影响状态码的“返回速度”——状态码是响应头的一部分，体积极小（通常几十字节），无论是否启用 Brotli，它都随首包（first byte）一同发出。真正影响移动端“感知敏捷度”的，是携带状态码的完整响应体（尤其是 JSON API 响应）的传输与解压耗时。用户说的“状态码返回敏捷”，实际指的是：API 响应快、首屏渲染早、错误反馈及时——而这高度依赖响应体（如 { "code": 0, "msg": "ok", "data": [...] }）是否被高效压缩、快速送达、低延迟解压。
要提升这一环节的移动端表现，关键不是优化状态码本身，而是围绕 API 响应体做 Brotli 的精准配置。以下是可直接落地的要点：
压缩级别设为 4，专供 JSON 响应
移动端高频调用的接口（如登录、列表、提交）返回的 JSON 通常在 1–50KB 区间，体积小、重复模式少（不像 HTML 有大量标签）。高压缩级（如 q=11）徒增服务端 CPU 开销，却几乎不缩小体积；q=4 是实测最优平衡点：
- 比 gzip 再省 12–18% 体积
- 动态压缩耗时比 q=5 低 35%，适合高并发 API 场景
- iOS/Android 主流机型解压 10KB JSON 耗时稳定 ≤ 3ms
确保 Nginx 中明确指定：
brotli_comp_level 4; brotli_types application/json text/plain;
启用 brotli_static always，消除运行时压缩开销
对固定结构的通用响应（如统一错误码模板 {"code":500,"msg":"server error"}），提前用 brotli -q 4 --gzip-fallback 生成 .br 文件，并配置：
brotli_static always;
这样 Nginx 直接返回预压缩文件，无 CPU 计算、无锁竞争、首字节时间（TTFB）趋近于纯静态资源——比动态压缩平均快 8–12ms（弱网下更明显）。
强制 Vary: Accept-Encoding 头，避免缓存错乱
Brotli 不支持 brotli_vary on 指令，必须手动加：
add_header Vary "Accept-Encoding";
否则 CDN 或代理可能把 br 响应缓存为未压缩版本，导致后续请求拿到错误编码，引发解析失败或空白页——这种“假慢”常被误判为状态码延迟。
关闭 gzip 冗余协商，防止降级干扰
很多配置残留 gzip on;，且未关闭：
gzip off; brotli on;
若两者共存，Nginx 可能因模块加载顺序返回 Content-Encoding: gzip（尤其当浏览器 header 同时带 br,gzip），不仅浪费 Brotli 优势，还让响应体多出 gzip 魔数（1f 8b），反而增加中间设备识别和拦截风险。
本质上，移动端 API 的“敏捷感”来自：小体积 + 快传输 + 零解压卡顿。Brotli q=4 + 预压缩 + 正确 Vary，三者协同，能让典型 JSON 响应在 3G 网络下首屏时间减少 15–20%，错误提示弹出更快、操作反馈更跟手。
