核心思路是预压缩替代实时压缩：构建阶段生成.br/.gz文件，nginx通过try_files匹配返回，零cpu开销；禁用brotli off和gzip on动态压缩，仅对text/html等类型启用轻量级brotli（level 2），严格配置vary和content-encoding响应头并实测验证。

核心思路不是压得更狠，而是让压缩“不发生在请求路径上”——把计算移出事件循环，用预压缩+静态服务替代实时编码。

静态资源必须预压缩，别碰动态压缩

前端构建产物（js/css/html/wasm）在 CI/CD 阶段就该生成 .br 和 .gz 文件，Nginx 只做文件存在性判断和头部注入，零运行时 CPU 开销。例如：

• Vite 或 Webpack 构建后加脚本：brotli -q 6 -w 24 *.js *.css *.html *.wasm
• Nginx location 块中禁用动态压缩：brotli off;，只靠 try_files $uri.br $uri.gz $uri =404;
• 确保 types 块包含 application/wasm wasm;，否则 .wasm.br 不触发

动态内容只配轻量级 Brotli，且严格限类型

API 返回的 JSON、模板渲染的 HTML 属于“一次写、多次读”，但不可预压缩。此时必须放弃高压缩率幻想：

• 设 brotli_comp_level 2; —— 实测比 gzip level 9 更省 CPU，压缩率却不低
• 仅对 text/html application/json application/javascript 启用，坚决剔除 image/* font/* application/pdf
• 配合 gzip_disable "msie6"; 避免旧客户端兼容负担

关键响应头一个都不能少

没这些头，浏览器要么当普通文件下载，要么缓存错版本：

• add_header Vary Accept-Encoding;：告诉 CDN 和代理，这个响应依赖编码协商
• add_header Content-Encoding br;：必须放在 try_files 成功匹配后，不能写在 server 顶层
• 确认 MIME 类型精准，比如用 application/javascript 而非 text/javascript

验证是否真生效

别信配置，要实测：

• curl -H "Accept-Encoding: br" -I https://yoursite.com/app.js | grep -E "(Content-Encoding|Vary)"
• Chrome DevTools → Network → 查看某 JS 请求的 Response Headers 是否含 Content-Encoding: br 和 Vary: Accept-Encoding
• 对比开启前后 TTFB 和 CPU 占用率（尤其高并发时）