构建出来的主包 gzip 之后还有 1.2MB 慢速 4G 下光下载就要 4 秒 同一个文件用 Brotli 预压缩只剩 780KB 但服务器根本没开这项配置。乍看像缓存或者权限的锅，追下去往往不是。
brotli -q 11 -k -f dist/app.js # nginx brotli_static on; brotli_types text/html application/javascript text/css;
追下去是这么回事：Brotli 对文本的压缩率一般比 gzip 高出两成 代价是压缩更慢一些 构建时预生成 br 文件就能避开运行时开销 只有动态压缩才需要权衡 CPU。
「Brotli 压缩」这类改动最怕改一半，回滚脚本先准备好，再动生产。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。
具体做法是，构建阶段预生成 br 文件 不要在请求时实时压缩大文件；在 Nginx 的配置里打开 brotli_static 并且让它排在 gzip 之前去优先判断；检查配置里的 brotli_types 列表 确认它包含 text/html 和 application/javascript 两类静态资源文件。
验收就看一点，响应头里出现 Content-Encoding br 文件体积比 gzip 小两成左右 首屏下载时间明显缩短。