vite静态资源处理需区分引入方式与打包规则：import引入参与构建并哈希重命名，public目录资源原样复制；支持?url、?raw等后缀控制加载行为；≤4kb资源默认base64内联，可配置assetsinlinelimit调整；通过assetfilenames等优化输出结构；配合compression插件启用brotli压缩，并按依赖拆分chunk。
在 Vite 构建中处理静态资源，核心是分清“怎么引入”和“怎么打包”两件事：引入方式决定资源是否参与构建图、是否被哈希重命名；打包规则则决定它最终落在哪、是否压缩、是否内联。两者配合得当，才能兼顾开发体验与生产性能。
图片、字体等资源的引入方式
资源引入不是只有 <img src="./logo.png"> 这一种写法，不同场景需匹配不同机制：
-
直接 import（推荐）：如
import logo from './logo.png'。Vite 会将其纳入构建流程，生成带 hash 的文件名（如logo.abc123.png），并在 JS 中返回解析后的 URL。CSS 中的url(./icon.svg)同理自动处理。 -
public 目录引用（不参与构建）：把
favicon.ico或robots.txt放进public/，代码中用绝对路径/favicon.ico引用。它不会被重命名、不压缩、不生成 hash，构建时原样复制到dist/根目录。 -
显式后缀控制行为：
-
import url from './file.js?url'→ 返回资源 URL 字符串，不执行内容； -
import text from './data.json?raw'→ 以字符串形式读取原始内容； -
import Worker from './worker.js?worker'→ 编译为独立 worker 脚本。
-
小资源内联 vs 大资源分离
Vite 默认对 ≤4KB 的图片、SVG、字体等转为 base64 内联进 JS/CSS，减少 HTTP 请求。这适合图标、小 logo 等；但若项目有大量动态拼接路径（如 require(`./imgs/${name}.png`)），内联会导致路径失效 —— 此时应禁用：
- 设
build.assetsInlineLimit: 0彻底关闭内联，所有图片都输出为独立文件； - 或按需调高阈值，如
8 * 1024（8KB），平衡请求数与包体积； - 注意：
build.lib模式下该配置无效，所有资源默认内联。
打包输出结构优化
默认所有资源都塞进 assets/ 目录，杂乱且不利于 CDN 缓存策略。可通过 rollupOptions.output.assetFileNames 按类型分流：
-
static/img/[name]-[hash].[ext]→ 图片统一进static/img/； -
static/font/[name]-[hash].[ext]→ 字体进static/font/； -
static/css/[name]-[hash].css→ CSS 单独归类； - 同时设置
chunkFileNames和entryFileNames统一 JS 输出路径，避免 JS 文件散落。
传输层压缩与大 chunk 拆分
打包只是第一步，真正减小网络体积靠的是传输压缩和合理拆包：
- 用
vite-plugin-compression生成.br（Brotli）和.gz文件，建议开启 Brotli（比 gzip 压缩率高 10–20%），并设threshold: 5120（5KB）避免压缩小文件得不偿失； - 当某个 chunk 超过 1MB，说明混入了过多第三方依赖。通过
rollupOptions.output.manualChunks按node_modules一级目录拆分，如把vue、lodash-es、element-plus各自打成独立 chunk，降低首屏加载压力。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
