直接用.br文件响应请求是节省nginx cpu最有效方式；需构建时生成同名.br文件、nginx配置brotli_static on及匹配types、确保权限正确，并通过curl或devtools验证content-encoding: br响应头。
直接用 .br 文件响应请求，跳过实时压缩计算，是节省 Nginx CPU 算力最直接有效的方式。关键不在“开不开 brotli_static”，而在于构建阶段产出 .br 文件 + Nginx 正确识别并返回它。
构建阶段必须生成 .br 文件
brotli_static 不会帮你压缩，只负责“找文件、发文件”。没 `.br`，它就静默跳过，不报错、不降级、也不 fallback。- Vite 项目：装
vite-plugin-compression，配置algorithm: 'brotliCompress'、ext: '.br'、threshold: 10240（≥10KB 才压） - Webpack 项目：用
compression-webpack-plugin，同样设algorithm: 'brotliCompress' - 手动补压也行：
bro --quality 6 app.js -o app.js.br，适合 CI 后处理或漏压资源
注意：.br 文件必须和源文件同目录、同名（如 app.js 对应 app.js.br），且建议保持时间戳一致（touch -r app.js app.js.br），避免缓存行为异常。
Nginx 配置要精准匹配路径与类型
brotli_static 的生效依赖两个硬条件：文件存在 + MIME 类型被明确允许。- 在服务静态资源的
location块内启用（不是全局http块）：brotli_static on;（或更激进的brotli_static always;，找不到.br时会 fallback 到动态 brotli） - 显式声明可服务类型：
brotli_types text/html application/javascript text/css application/json image/svg+xml;
别写text/javascript（Chrome 已弃用），也别漏掉text/html（首屏 HTML 压缩收益最大） - 若同时启用了
gzip_static或 PHP 环境，务必关掉冲突项：gzip_static off;
权限和属主决定文件能否被读取
文件存在 ≠ Nginx 能读。worker 进程以什么用户身份运行，`.br` 文件就得归谁所有。- 查 Nginx 运行用户：
ps aux | grep nginx，常见为www或nginx - 查文件权限：
ls -l /path/to/app.js.br，确保属主属组匹配（如www:www） - 权限不对就修正：
chown www:www /path/to/app.js.br - 注意：brotli_static 不写日志、不报错——权限错就是静默失败，这是最常被忽略的排查点。
验证是否真正生效
不能只看配置语法正确，得确认浏览器实际收到了 `.br` 文件。- 用 curl 检查响应头：
curl -H "Accept-Encoding: br" -I https://yoursite.com/app.js
应看到Content-Encoding: br和明显变小的Content-Length - 在 Chrome DevTools 的 Network 标签页里，选中资源，看 Response Headers 是否含
br，对比原始体积（比如app.js原 286KB，压缩后应降到 ~200KB 左右） - 若没生效，优先检查
.br文件是否存在、权限是否对、brotli_types是否覆盖该资源类型
不复杂但容易忽略
