使用 Data URI 嵌入图像 - Base64 编码原理与最佳实践
什么是 Data URI 方案 - 将图像作为文本嵌入
Data URI(Data URL)方案将数据直接编码在 URL 中，而非引用外部文件。它在 RFC 2397 中定义，可以将图像、字体、CSS、JavaScript 及任意数据直接嵌入 HTML 和 CSS 文件中。
Data URI 的基本格式：data:[mediatype][;base64],data
- mediatype:MIME 类型，如
image/png、image/svg+xml、image/jpeg - base64：表示数据使用 Base64 编码(二进制数据必须)
- data：实际的编码数据字符串
示例：<img src="data:image/png;base64,iVBORw0KGgo...">
这种方式消除了对外部文件的 HTTP 请求，将图像数据直接包含在文档中。浏览器解析 HTML/CSS 时即可立即渲染图像，无需等待额外的网络往返。
完整语法为 data:[<mediatype>][;base64],<data>，其中媒体类型部分可以写作 image/jpeg、image/svg+xml、image/webp 等。以一张 1x1 像素的透明 PNG 为例，其完整形式是 data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==，文档中通常简写为 ,iVBOR... 来省略冗长的数据主体。四个组成部分分别是：data: 为方案标识符，紧随其后的媒体类型指定图像格式，;base64 声明编码方式，逗号之后才是真正的图像数据。
Base64 编码原理与大小影响
Base64 将二进制数据转换为 ASCII 字符串，方法是将数据拆分为 6 位一组并映射到 64 个字符(A-Z、a-z、0-9、+、/)，导致数据大小比原始数据增加约 33%。
编码过程：
- 每 3 字节(24 位)的二进制数据被拆分为 4 个 6 位组
- 每个 6 位组映射为一个 Base64 字符
- 如果输入字节数不是 3 的倍数，使用
=进行填充
大小影响的计算：原始文件 1KB → Base64 后约 1.37KB。这个 33% 的膨胀意味着 10KB 的图像变为约 13.3KB 的文本。此外，Base64 字符串嵌入 HTML/CSS 后无法被单独缓存，每次页面加载都会传输完整数据。
与 gzip 压缩的关系：虽然 Base64 数据本身增大了 33%，但 HTML/CSS 文件通常会经过 gzip 压缩传输。gzip 对 Base64 文本的压缩效果约为 10-15%，部分抵消了膨胀。但总体而言，Base64 嵌入的图像仍比独立文件传输更大。
编码表由 A-Z（26 个字母）、a-z（26 个字母）、0-9（10 个数字）以及 +/ 两个符号，共 64 个字符组成；输入长度不是 3 的倍数时用 = 补齐。命令行转换在 macOS 上是 base64 -i icon.png -o icon.txt，在 Linux 上是 base64 icon.png > icon.txt。JavaScript 中可以写成 const toDataUri = (file) => new Promise((resolve) => { const reader = new FileReader(); reader.onload = () => resolve(reader.result); reader.readAsDataURL(file); });。体积膨胀的实际影响值得逐档记住：1KB 的图标变成 1.37KB（增加 0.37KB，可以接受），10KB 的缩略图变成 13.7KB（增加 3.7KB，需要斟酌），100KB 的照片变成 137KB（增加 37KB，不建议），1MB 的图像变成 1.37MB（增加 370KB，务必避免）。
在 HTML 和 CSS 中使用 Data URI
Data URI 可用于 HTML 的 <img> 标签和 CSS 的 background-image 属性。各有特定的语法和适用场景。
HTML 用法：<img src="data:image/png;base64,iVBORw0KGgo..." alt="图标">
CSS 用法：.icon { background-image: url("data:image/svg+xml,%3Csvg..."); }
SVG 的特殊处理：
- SVG 是文本格式，可以不使用 Base64 而直接 URL 编码嵌入
- URL 编码的 SVG 比 Base64 编码更小(无 33% 膨胀)
- 格式：
data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'...%3E...%3C/svg%3E - 需要转义的字符：
#→%23、<→%3C、>→%3E
CSS 中的注意事项：Data URI 字符串可能非常长，影响 CSS 文件的可读性。建议通过构建工具自动生成，而非手动编写。CSS 中的 Data URI 会随样式表一起缓存，适合在多个页面共享的小图标。
HTML 中的完整写法是 <img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiI+PHJlY3Qgd2lkdGg9IjE2IiBoZWlnaHQ9IjE2IiBmaWxsPSIjY2NjIi8+PC9zdmc+" alt="placeholder" width="16" height="16" />。CSS 中则可以写成 .icon-check { background-image: url('data:image/svg+xml,%3Csvg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"%3E%3Cpath d="M9 16.17L4.83 12l-1.42 1.41L9 19 21 7l-1.41-1.41z"/%3E%3C/svg%3E'); }。SVG 的优化要点是不必经过 Base64：直接用百分号编码嵌入，体积增幅可以从 33% 压到 10-15% 左右，而且只需要最少的转义（< 换成 %3C、> 换成 %3E、# 换成 %23、双引号换成单引号）。自定义属性无法在 SVG 内部被引用，所以不要指望 --icon-color 生效，改用 currentColor 就能通过 CSS 的 color 属性控制图标颜色。与 CSS Sprites（把多个小图合成一张、再用 background-position 裁切）相比，哪一种更合适要看具体场景；在 HTTP/2 环境下独立文件已经没有明显劣势，因此保留独立的 SVG 文件并用 <use> 引用，才是现代的首选做法。
性能影响 - Data URI 的优势与劣势
准确理解 Data URI 的性能特征才能确保恰当使用。HTTP/1.1 时代的最佳实践在 HTTP/2 下可能适得其反。
优势：
- 减少 HTTP 请求：在 HTTP/1.1 下，浏览器对同一域名的并发连接数有限(通常 6 个)。将小图像内联可减少请求队列阻塞
- 消除连接开销:DNS 查询、TCP 握手、TLS 协商等开销对小文件影响显著。内联完全消除这些开销
- 避免额外往返：关键渲染路径上的小图像(如 logo、图标)内联后可随 HTML 一起到达，无需等待额外请求
劣势：
- 无法独立缓存:Data URI 嵌入在 HTML/CSS 中，无法被浏览器单独缓存。页面更新时即使图像未变也需重新下载
- 体积膨胀 33%:Base64 编码增加约 1/3 的数据量，增加传输负担
- 阻塞渲染：大型 Data URI 嵌入 CSS 中会延迟样式表解析，阻塞页面渲染
- HTTP/2 下优势减弱:HTTP/2 的多路复用消除了并发连接限制，小文件的独立请求开销大幅降低
与 Core Web Vitals 的关系也需要一并考虑：体积较大的 Data URI 会增加 HTML 的下载量，从而推迟 FCP（First Contentful Paint）；如果把 LCP 元素本身写成 Data URI，LCP 得分会明显恶化。另一个容易忽略的坑是 CSP（Content Security Policy）：策略为 img-src 'self' 时 Data URI 会被直接拦截，必须显式加入 data: 才能放行。此外，过长的 Data URI 还会拖慢 HTML 解析器的处理速度。
适用场景与应避免的情况
明确区分 Data URI 何时有益、何时有害。判断标准：图像大小、复用频率和缓存重要性。
适用场景：
- 1KB 以下的微型图标:HTTP 请求的开销(DNS + TCP + TLS)可能超过图标本身的大小。内联消除了这种不成比例的开销
- 关键渲染路径上的图像：首屏必须立即显示的 logo 或加载指示器，内联可避免额外的网络往返
- CSS 精灵图的替代：少量小图标可用 Data URI 替代传统精灵图，简化维护
- 邮件模板:HTML 邮件中外部图像常被邮件客户端阻止，Data URI 可确保图像始终显示
- 单页应用的初始加载:SPA 的 shell 中包含的少量 UI 图标，内联可加速首次渲染
应避免的情况：
- 大于 5KB 的图像:Base64 膨胀后超过 6.5KB，独立文件 + 缓存更高效
- 频繁复用的图像：多处使用的图像应作为独立文件以利用浏览器缓存
- 需要响应式的图像:Data URI 无法配合
srcset和<picture>实现响应式加载 - HTTP/2 环境下的批量小文件：多路复用使独立请求的开销极低，内联的收益不再明显
判断标准可以更具体一些：包含 Base64 膨胀后仍然小于 1.5KB 的资源，值得用内联省下一次 HTTP 请求的开销（DNS 加 TCP 加 TLS 合计约 50-200ms）。LQIP（Low Quality Image Placeholder）是另一个典型用途，即延迟加载时先行显示的极小模糊占位图，常见规格是 20-50 字节的 1x1 像素图，或者 200-500 字节的超低分辨率缩略图。CSS 中的装饰性 SVG，例如边框装饰、背景纹理、自定义列表符号，同样适合内联。反过来说，作为 LCP（Largest Contentful Paint）目标的主视觉与首屏大图不应内联，因为 HTML 体积的增加会直接拖慢 LCP。
构建工具自动化与实现模式
将 Data URI 生成集成到构建流水线中，消除手动编码的工作。
webpack 自动内联：
- asset/inline:webpack 5 的 Asset Modules 可根据文件大小自动决定内联或独立文件。设置
parser.dataUrlCondition.maxSize阈值(推荐 4KB) - 配置示例：
{ test: /\.(png|jpg|gif|svg)$/, type: 'asset', parser: { dataUrlCondition: { maxSize: 4 * 1024 } } }
Vite 的处理：
- Vite 默认将 4KB 以下的资源内联为 Data URI
- 通过
build.assetsInlineLimit配置阈值 - SVG 可通过插件转为 Vue/React 组件而非 Data URI
PostCSS 插件：
postcss-url插件可自动将 CSS 中引用的小图像转为 Data URI- 配置
url({ filter: '**/*.svg', url: 'inline', maxSize: 4 })
Node.js 手动生成：const dataUri = 'data:image/png;base64,' + fs.readFileSync(path).toString('base64')
构建工具的阈值设定是落地的关键。webpack 5 的 Asset Modules 可以写作 { test: /\.(png|svg)$/, type: 'asset', parser: { dataUrlCondition: { maxSize: 4096 } } }，即 4KB 以下自动转为 Data URI，超过则输出为独立文件；Vite 通过 build: { assetsInlineLimit: 2048 } 把阈值改为 2KB，个别文件可以用 import icon from './icon.svg?inline' 强制内联。Next.js 方面，next/image 的 placeholder="blur" 会自动生成 LQIP；若需要自定义，可以用 plaiceholder 从任意图像生成超低分辨率的 Base64 占位图。CI/CD 上建议用 bundlesize 或者 Lighthouse CI 设定阈值，一旦内联过度导致文件膨胀就立刻告警。