大型静态资源需分层处理：小资源内联（≤4kb）、中等资源分类输出+哈希命名+cdn差异化缓存、超大资源主动拆包+预压缩（brotli/gzip）；禁用大资源内联，避免js包膨胀，并确保服务器启用brotli_static/gzip_static。
大型静态资源在 Vite 构建中不能靠“一刀切压缩”解决，核心是分层应对：小资源内联、中等资源分类存放+传输压缩、超大资源主动拆包+预压缩。直接对 5MB 的图片或字体文件启用 gzip，效果微乎其微，还可能拖慢构建；真正有效的策略是组合使用体积控制、结构优化和传输压缩。
控制内联阈值，避免大资源误入代码
Vite 默认把 ≤4KB 的图片、SVG、字体等转为 base64 内联进 JS/CSS。这对图标很友好，但若资源本身较大（比如一张 2MB 的 banner 图），必须阻止它被内联——否则会显著膨胀 JS 包体积，甚至触发 Rollup 警告。
- 显式设低阈值：build.assetsInlineLimit: 4096（保持默认即可，不建议调高）
- 确认资源路径未被意外匹配：检查是否因别名（如
@assets）或相对路径写法，导致大图被当作模块导入而非静态引用 - 对明确的大资源，改用
<img src="/static/xxx.jpg">或 CSSurl(/static/xxx.webp)引用，绕过模块解析流程
分类输出 + 文件哈希，提升 CDN 缓存命中率
所有资源塞进 assets/ 目录不仅混乱，还会让 CDN 难以设置差异化缓存策略（例如字体需长期缓存，JS 需强校验）。通过 Rollup 配置按类型分离，并带内容哈希命名：
-
图片/字体/SVG →
static/img/[name]-[hash].[ext] -
CSS →
static/css/[name]-[hash].css -
JS chunk →
static/js/[name]-[hash].js - 关键点：
assetFileNames中的[ext]占位符能自动识别后缀，无需手动判断
用 vite-plugin-compression 做传输级预压缩
这是针对大型静态资源最直接有效的压缩手段：构建时生成 .br（Brotli）和/或 .gz 文件，由 Nginx/Apache 在响应时根据 Accept-Encoding 自动返回对应格式，浏览器解压后使用——体积可减少 30%~70%，且不增加运行时开销。
- 安装：
npm install vite-plugin-compression -D - 推荐配置（兼顾压缩率与构建速度）：
algorithm: 'brotli'（比 gzip 高效 15% 左右），threshold: 5120（≥5KB 才压缩），deleteOriginFile: false（保留原始文件，兼容不支持 Brotli 的旧客户端） - ⚠️ 注意：插件只生成文件，**必须在服务器上开启 brotli_static / gzip_static 模块并配置响应头**，否则无效
对超大依赖或资源做 manualChunks 拆分
当某个 chunk 文件 >1MB（常见于未拆分的 UI 库、图表库、富文本组件），说明它混入了大量第三方代码。这类“伪静态资源”应从主包中剥离：
- 在
rollupOptions.output.manualChunks中按一级 node_modules 目录拆：vue、element-plus、echarts各自成 chunk，命名如static/js/chunk-element-plus-[hash].js - 配合
build.chunkSizeWarningLimit: 1500抑制警告（仅视觉层面），本质仍需拆分 - 对特别大的本地资源（如 PDF 模板、音视频素材），建议移出构建流程，改用独立 CDN 或后端接口提供
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
