不会。HTML解析器仅识别data: URL语法，不执行Base64解码；解码由图像渲染管线在懒加载时于非主线程完成，产生字符串与位图双内存副本，且CSS background-image比<img src>更早触发解码、无法共享缓存。
HTML解析器是否会对data:image;base64字符串做额外解析？
不会。浏览器在HTML解析阶段只做语法识别，src属性值只要符合URL格式（包括data:前缀），就直接交给资源加载子系统处理，不触发Base64解码。解码动作发生在图像渲染管线中，且是懒执行的——只有当该<img>进入可视区域或被JS显式调用decode()时才真正解码。
Base64解码发生在哪个阶段？CPU和内存开销在哪？
解码发生在图像解码线程（非主线程），但会占用额外内存：Base64字符串本身需完整保留在DOM树中，解码后生成的位图数据又是一份独立内存副本。这意味着同一张图实际驻留两份数据——原始字符串 + 解码后像素缓冲区。
- 典型损耗：一张1.5KB原始PNG，Base64编码后约2KB字符串；解码后生成RGBA位图，假设尺寸为100×100，即40KB内存（4字节/像素）
- CPU峰值出现在首次绘制帧，尤其是多张Data URI图片集中渲染时，可能触发主线程卡顿
- Chrome DevTools的
Memory > Heap Snapshot可观察到DOMString与ImageBitmap对象同时存在
为什么CSS里用background-image: url(data:...)比HTML里<img src="data:...">更慢？
因为CSS背景图即使未显示（如display: none或不在视口），只要样式规则被计算过，浏览器就可能提前触发解码准备；而<img>有明确的加载生命周期控制（loading="lazy"生效，decode()可延迟）。
- CSS中Data URI会随样式表解析立即进入资源队列，无法被懒加载机制拦截
- 若该CSS被多个元素复用（比如通用类
.icon），每处使用都触发独立解码，无法共享位图缓存 - 实测：10个相同Data URI背景图的
div，比10个相同<img>标签内存占用高约3倍
IE8/IE9下Data URI解析失败的隐藏原因
不是单纯长度超限，而是解析器对data: URL的token分割逻辑有缺陷：遇到Base64字符串中连续出现的+或/符号时，IE8会误判为URI分隔符，导致截断。这不是Base64标准问题，是IE解析器正则表达式写死了分界规则。
立即学习“前端免费学习笔记（深入）”；
- 现象：
data:image/png;base64,iVBORw0KGgo...中间某段含+/+序列，IE8只取前半截，解码失败后静默回退为空图 - 规避方法：服务端生成时启用
base64url编码（替换+//为-/_），但IE8根本不支持该变体 - 真实底线：IE8仅可靠支持≤32KB的Base64字符串，且必须确保无连续特殊字符组合
