vite 的 assetsinlinelimit 仅对生产构建生效,控制静态资源 base64 内联阈值(默认 4096 字节),开发环境完全忽略该配置,所有资源均通过 http 实时加载。

在 JavaScript 中配置 Vite 的静态资源内联阈值,核心是设置 build.assetsInlineLimit,但必须明确一点:这个配置只对生产构建(vite build)生效,开发服务器(vite dev)完全不认它。
✅ 生产环境:控制 base64 内联的临界值
小于等于该阈值的图片、字体等静态资源,在打包时会被转为 base64 字符串并直接写入 JS/CSS/HTML;超过则输出为独立文件(带哈希名),便于缓存和按需加载。
- 默认值是 4096(即 4KB)
- 单位是字节,可设为数字或字符串(如
8 * 1024表示 8KB) - 设为
0可彻底禁用内联(所有资源都输出为单独文件)
配置方式(vite.config.js 或 vite.config.ts):
export default defineConfig({
build: {
assetsInlineLimit: 8 * 1024 // 8KB 以内才内联
}
})
⚠️ 开发环境:assetsInlineLimit 不起作用
开发时 Vite 使用基于原生 ES 模块的按需服务机制,所有静态资源都通过 HTTP 请求实时返回,不会转 base64,也不受 assetsInlineLimit 控制。你看到的小图直接显示、大图也能正常加载,是因为开发服务器内置了资源中间件,自动处理路径与 MIME 类型,和打包逻辑无关。
- 想验证?打开浏览器开发者工具 → Network 标签页 → 查看图片请求,响应体是原始二进制,不是 data URL
- 如果硬要在开发时模拟内联效果,需手动用
new URL('./xxx.png', import.meta.url).href+fetch+FileReader转 base64,但这属于业务代码,非构建配置
? 其他相关资源处理要点
除了内联阈值,还有几个关键配置影响静态资源行为:
-
public目录中的文件:始终原样复制到dist,不参与内联或哈希重命名,适合 favicon、robots.txt 等必须固定路径的资源 -
build.lib模式下:assetsInlineLimit会被忽略,所有资源强制内联(适用于打包 UI 组件库) -
引用方式决定是否受控:用
import xxx from './img.png'才走内联逻辑;用<img src="/public/logo.png">则绕过构建系统,不受任何阈值影响
? 实际调试建议
修改配置后,务必用真实构建验证效果:
- 运行
vite build,检查dist输出目录:小图是否消失(已内联)、大图是否生成xxx.hash.png - 查看生成的 JS 或 CSS 文件,搜索
data:image/确认 base64 是否写入 - 不要依赖开发时的控制台日志或网络请求来判断内联是否生效——那只是开发服务的行为
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南











