Nginx启用Brotli需先编译ngx_brotli模块，再按资源类型分级设置压缩级别：静态资源用level 8–11预压缩，打包产物用level 6，动态内容限level 1–4；仅对text/html、application/javascript等可压缩类型启用，并配合gzip兜底。
要在Nginx中用好Brotli，核心不是“压得越狠越好”，而是分清哪些内容该预压缩、哪些该轻量实时压、哪些根本不用压——这样既能保住压缩率，又不把CPU拖垮。
必须先编译模块，否则所有配置都无效
Brotli不是Nginx自带功能，apt或宝塔直接装的默认都不含。你得自己编译：
- 克隆
ngx_brotli仓库，并递归拉取brotli子模块（git clone --recurse-submodules https://github.com/google/ngx_brotli） - 进入
deps/brotli目录，用cmake -DBUILD_SHARED_LIBS=OFF构建静态库 - Nginx编译时加上
--add-module=/path/to/ngx_brotli，缺了这句，brotli on会报“unknown directive” - 装完后运行
nginx -V 2>&1 | grep with-http_brotli_module，确认模块已注入
按资源类型分级设压缩级别
统一设brotli_comp_level 11是CPU飙升的主因。不同内容要区别对待：
-
长期不变的静态资源（如
reset.css、logo.svg）：用level 8–11，配合brotli_static on预压缩，零运行时开销 -
前端打包产物（如
app-xxx.js、chunk-vendors.css）：推荐level 6，压缩率约65%，TTFB增加可控 -
动态内容（HTML模板、API返回的JSON）：严格限制在
level 1–4，实测比gzip 9级还省CPU且压缩率更高
只对真正可压缩的内容启用Brotli
乱加brotli_types等于给CPU加无谓负担。务必排除已压缩格式：
- 保留：
text/html text/css application/javascript application/json - 剔除：
image/svg+xml font/woff2 image/png application/pdf等二进制类型 - MIME类型要精准，比如用
application/javascript而非过时的text/javascript，否则Chrome可能忽略 - 建议在
location块里精细控制，例如：
location ~ \.js$ {
brotli_static on;
brotli on;
brotli_types application/javascript;
brotli_comp_level 6;
}
预压缩 + gzip兜底，双保险不踩坑
brotli_static on不会帮你生成.br文件，它只检查同名.br是否存在——没文件就跳过，不降级也不报错。
- 前端构建阶段就要产出.br：Vite项目配
vite-plugin-compression，Webpack用compression-webpack-plugin，指定algorithm: 'brotliCompress' - .br文件权限必须为Nginx worker进程可读（常见坑：权限644不够，建议644或755，属主设为
www-data或nginx） - 始终保留gzip配置，因为部分爬虫、老旧代理、内网设备仍不支持Brotli；靠
Accept-Encoding头自动路由，别指望100% Brotli覆盖 - 验证是否生效：看响应头是否有
Content-Encoding: br，且Content-Length明显小于原始大小
