验证 nginx brotli 在移动端真实适配需端到端确认：弱网下测传输大小缩减率（brotli 比未压缩小 30%+、比 gzip 小 15–20%），检查 ttfb 是否因高压缩级升高，实机验证解压执行与渲染，排查 accept-encoding 协商、vary 缓存、gzip 冗余及 https 强制前提。
验证 Nginx Brotli 在移动端网络下的真实适配表现，不能只看响应头是否含 content-encoding: br，而要结合弱网特征、设备解压能力与实际传输链路做端到端确认。重点是测“用户真能拿到、真能快速解压、真不卡顿”。
用真实弱网环境抓取关键指标
在 Chrome DevTools 或 Safari Web Inspector 中开启「Network Conditions」，模拟 3G（1.6 Mbps / 150ms RTT）或更严苛的 Slow 3G（0.75 Mbps / 200ms RTT），然后刷新页面：
- 逐个检查 HTML、CSS、JS、JSON 资源的 Response Headers，确认
Content-Encoding: br出现在所有目标类型上（如text/html、application/json） - 对比同一资源在「无节流」和「Slow 3G」下的 Size（Transfer Size）：Brotli 应比未压缩小 30%+，比 Gzip 小 15–20%
- 观察 Waterfall 图中 TTFB 和 Content Download 时间占比：若 TTFB 明显升高（>100ms），说明动态压缩拖慢首字节；此时应检查是否误启高压缩级或未启用
brotli_static always
验证移动端设备能否正确解压并渲染
Brotli 解压失败不会报错，但可能表现为白屏、脚本不执行或 JSON 解析异常。需主动验证：
- 在 iOS Safari 和 Android Chrome 上打开控制台，访问一个返回
Content-Encoding: br的 JSON 接口（如/api/status），执行：fetch('/api/status').then(r => r.json()).then(console.log).catch(e => console.error('解压/解析失败:', e)) - 对关键 JS 文件，可临时加一段检测逻辑：
if (typeof window !== 'undefined' && !window.brotliTested) { console.log('Brotli 已生效且 JS 可执行'); window.brotliTested = true; } - 使用 WebPageTest（选择 Android Moto G4 / 3G）跑真实设备实测，查看「First Visual Change」和「Document Complete」时间是否随 Brotli 开启明显提前
排查常见移动端适配断点
很多“看似启用”实则失效的问题集中在协商与缓存环节：
-
确认 Accept-Encoding 请求头真实包含
br：用 Charles 或 mitmproxy 抓包，过滤请求头，避免 CDN 或中间代理清除了br（尤其某些老旧 WAF 会强制降级） -
检查 Vary 响应头是否完整：必须有
Vary: Accept-Encoding，否则 CDN 可能将 br 响应缓存为无压缩版本，后续非 br 请求拿到乱码 -
禁用 gzip 冗余配置：确保配置中明确写了
gzip off;，避免 Nginx 因模块加载顺序错误返回Content-Encoding: gzip（移动端浏览器发的是br,gzip，但服务端协商出错） -
HTTPS 强制前提：所有现代浏览器仅在 HTTPS 下发送
Accept-Encoding: br，HTTP 站点即使配置了 Brotli 也完全不会触发
自动化回归验证建议
每次上线前可用简单脚本快速筛查：
- 用 curl 模拟移动端请求：
curl -sI -H "Accept-Encoding: br" -H "User-Agent: Mozilla/5.0 (Linux; Android 10) AppleWebKit/537.36" https://yoursite.com/app.js | grep -i "content-encoding\|vary" - 批量检查关键资源是否一致：
for f in index.html app.css main.js; do echo $f; curl -s -H "Accept-Encoding: br" https://yoursite.com/$f | brotli -t - 2>/dev/null || echo "❌ $f 解压失败"; done
