Nginx 不预压缩也不同步文件，仅按配置返回已存在的 .br 文件；同步责任在构建部署流程：构建时需生成配套 .br 文件，部署时原子替换整套资源，Nginx 配置 brotli_static always 并关闭 gzip，最后实测响应头、大小及错误日志验证。
Nginx 本身不负责预压缩文件的同步，它只按配置查找并直接返回已存在的 .br 文件。源文件更新后，.br 文件是否同步、何时同步、由谁触发——完全取决于构建和部署流程的设计。关键不是让 Nginx “感知变化”，而是确保 .br 文件在源文件变更后确定性地、原子性地、可验证地一同发布。
构建阶段必须生成配套的 .br 文件
静态资源（如 app.js、style.css、index.html）在打包时就要同步产出同名 .br 文件，并保留原始文件。这一步不能依赖上线后再补压，否则会出现“有源无压”或“压错版本”的问题。
- 使用 Vite：配
vite-plugin-compression，设algorithm: 'brotliCompress'、ext: '.br'、threshold: 10240（≥10KB 才压） - 使用 Webpack：用
compression-webpack-plugin，同样指定algorithm: 'brotliCompress' - 纯静态站点：用脚本批量处理，例如：
find dist -type f \( -name "*.js" -o -name "*.css" -o -name "*.html" \) -exec brotli -q 6 -k {} \;注意加
-k参数保留原始时间戳，避免 Nginx 因.br文件比源文件旧而降级
部署必须原子替换整套文件
.br 文件不是独立更新项，而是和源文件构成逻辑对。部署时应整体拷贝或切换符号链接（如 dist → dist-v2），确保：
- 源文件与对应
.br文件始终在同一个发布单元内 - 不出现
dist/app.js已更新但dist/app.js.br还是旧版的情况 - 若用 rsync 或 SCP，需带
-a（归档模式）并校验文件数与大小一致性
Nginx 配置要强制走预压缩路径，不回落
brotli_static always 必须放在 http{} 或 server{} 块顶层，且搭配 gzip off：
http {
brotli_static always;
brotli_types text/html text/css application/javascript application/json image/svg+xml;
gzip off;
}always 表示：只要磁盘上存在 .br 文件，就必须返回它，绝不 fallback 到源文件或实时压缩。这样能彻底规避“源文件更新了但 .br 没跟上”导致的响应不一致风险。
验证同步是否真正生效
上线后不能只看配置，要实测：
- 请求一个刚更新的 JS 文件，带
Accept-Encoding: br头，检查响应头是否有Content-Encoding: br - 对比响应体大小是否接近本地构建生成的
.br文件大小（偏差应 < 100 字节） - 检查 Nginx 错误日志，确认无
*.*.br not found类警告（说明没找到预压文件，已悄悄降级）
不复杂但容易忽略
