核心是验证精准分发、稳定缓存与一致性：用curl检查content-encoding是否匹配accept-encoding，确认预压缩文件存在且生效，确保vary: accept-encoding头正确发出以避免cdn缓存错版本。
测试 Brotli 与 Gzip 混合配置的最优解，核心不是比谁压缩率高，而是验证“请求进来时能否精准分发、响应出去时是否稳定可缓存、资源变更后是否不破环一致性”。重点看三件事：能否正确识别 Accept-Encoding 并返回对应编码、预压缩文件是否真实生效、CDN 或代理层是否按 Vary: Accept-Encoding 正确区分缓存。
用 curl 验证实际响应编码
这是最直接、零依赖的验证方式。在服务器本地或可信网络环境执行：
- 查 Brotli 是否命中：
curl -I -H "Accept-Encoding: br" https://yoursite.com/app.js，响应头中应含Content-Encoding: br且Content-Length明显小于原始大小 - 查 Gzip 回退是否生效：
curl -I -H "Accept-Encoding: gzip" https://yoursite.com/app.js，响应头应为Content-Encoding: gzip - 查无压缩兜底：
curl -I -H "Accept-Encoding: identity" https://yoursite.com/app.js，响应头不应含Content-Encoding，且Content-Length应与磁盘上原始文件一致 - 注意：所有测试必须使用真实存在的
.br和.gz文件（如app.js.br、app.js.gz），否则 Nginx 会静默跳过static on模式，转而尝试动态压缩（或完全不压）
检查 Nginx 日志与响应头完整性
光看 Content-Encoding 不够，还要确认关键协商头是否发出：
- 启用
log_format记录$sent_http_content_encoding和$sent_http_vary，例如：log_format debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_accept_encoding" "$sent_http_content_encoding" "$sent_http_vary"'; - 正常响应中，
$sent_http_vary必须恒为Accept-Encoding；若为空，说明brotli_vary on或gzip_vary on未生效，CDN 极可能缓存错版本 - 对同一 URL 发起不同
Accept-Encoding请求，日志中$sent_http_content_encoding应随请求头变化，而非固定为某一种
用真实构建产物压测 CPU 与 TTFB
避免只测单文件，要模拟生产发布后的典型访问模式：
- 准备包含 HTML、CSS、JS、SVG 的最小静态站点（如 Vite 构建的
dist/目录），并确保已用brotli --quality=9和gzip -6生成全部.br与.gz文件 - 用
ab或wrk对首页发起并发请求（如wrk -t4 -c100 -d30s https://yoursite.com/），同时监控：
–top中nginx: worker process的 CPU 占用
–nginxaccess log 中平均$request_time（首字节时间 TTFB 的代理指标）
– 各资源的Content-Length是否始终稳定（排除动态压缩抖动） - 对比两组配置：
✅brotli_static on; gzip_static on;（推荐）
❌brotli on; gzip on;（禁用 static，强制实时压缩）
前者 CPU 增幅通常
浏览器 DevTools 端到端确认
最终交付效果必须在真实客户端可见：
- Chrome / Edge / Firefox 打开 Network 面板，刷新页面，筛选
js或css类型，查看每项的Content-Encoding列值应为br（现代浏览器）或gzip（IE、旧安卓 WebView） - 右键任意一个
br资源 → “Copy” → “Copy response”，粘贴进文本编辑器，确认内容可读（非乱码），证明解压链路完整 - 打开 Application → Clear storage → 清空所有缓存和 Service Worker，再刷新，观察是否仍能加载
.br文件（验证预压缩路径未被绕过）
