现代打包工具通过构建阶段预生成.gz/.br文件实现传输压缩，Nginx用gzip_static/brotli_static优先返回静态压缩文件并自动降级，Apache需重写规则+手动设头，最终须在Chrome Network中验证content-encoding与Vary头。
现代打包工具本身不直接执行服务器端压缩，而是配合构建阶段预生成 .gz 或 .br 文件，再由 Nginx/Apache 在响应时优先返回这些静态压缩文件——这才是“传输极致瘦身”的可靠路径。关键不是让服务器实时压缩，而是把压缩工作前移到构建时，避免运行时开销，同时确保浏览器能拿到最小体积的资源。
构建阶段：用插件批量生成预压缩文件
所有主流构建工具（Vite、Webpack、Rollup）都支持在打包输出时同步生成 .gz 和 .br 文件，只需配置对应插件：
-
Vite：推荐
vite-plugin-compression，启用 Brotli 时设algorithm: 'brotliCompress'，并开启deleteOriginFile: false保留原始文件；threshold: 1024表示仅压缩 ≥1KB 的资源，避免小文件负优化。 -
Webpack（Vue/React 项目常用）：用
compression-webpack-plugin，指定algorithm: 'brotliCompress'，compressionOptions: { level: 5 }是 HTML/JS/CSS 的合理平衡点；注意test正则要覆盖.html，否则首屏 HTML 不会被压缩。 -
产出验证：构建后检查
dist/目录是否出现index.js.br、style.css.gz等同名压缩文件，且权限可读（尤其 Linux 服务器需确认文件属主和 chmod）。
Nginx 配置：优先服务预压缩文件，自动降级兜底
预压缩文件只有被 Web 服务器正确识别并响应，才能生效。Nginx 的 gzip_static on 和 brotli_static always 是核心指令：
- 启用
gzip_static on;后，Nginx 收到请求时会先查找同名.gz文件，存在则直接返回，并自动添加Content-Encoding: gzip和正确Content-Type。 - 启用
brotli_static always;（需 ngx_brotli 模块），逻辑相同，但优先级高于 gzip：当客户端声明Accept-Encoding: br,gzip，Nginx 优先返回.br文件；若无.br则回落到.gz；若两者皆无，才触发动态压缩（不推荐依赖此路径）。 - 必须保留
gzip on;和brotli on;共存，确保旧浏览器或不支持 Brotli 的客户端仍能获得 gzip 压缩，不破坏兼容性。
Apache 用户：靠重写规则 + 手动响应头模拟预压缩
Apache 没有原生 *_static 指令，需组合 mod_rewrite 和 mod_headers 实现类似效果：
- 用
RewriteCond %{HTTP:Accept-Encoding} br判断支持，再用RewriteCond %{REQUEST_FILENAME}.br -f确认文件存在，最后RewriteRule ^(.+)$ $1.br [QSA,L]重写路径。 - 必须为每种压缩后缀单独设置响应头：
<FilesMatch "\.js\.br$">Header set Content-Encoding "br"Header set Content-Type "application/javascript; charset=utf-8"</FilesMatch>——漏掉Content-Type会导致 JS/CSS 解析失败。 - Brotli 静态支持维护成本高，生产环境建议迁移到 Nginx 或使用 CDN（如 Cloudflare、又拍云）自动处理 .br 回源与缓存。
验证与调优：看真实网络面板，不看构建体积
构建生成了 .br 文件 ≠ 浏览器收到了 br 响应。最终验证必须在 Chrome DevTools Network 标签中进行：
- 刷新页面后，选中任意 JS/CSS/HTML 请求，在 Response Headers 中确认
content-encoding: br或gzip； - 对比 Size（传输大小）与 Content（解压后大小），差值越大说明压缩越有效；
- 检查是否有
Vary: Accept-Encoding，缺失会导致 CDN 缓存混淆，同一 URL 可能错误返回 gzip 版本给声明支持 br 的客户端。
