海量Data-URI图片会显著拖慢HTML解析，因其在Tokenizer阶段生成超长base64文本token，导致内存与字符串处理开销剧增、触发缓冲区重分配及GC暂停，阻塞DOM构建、延迟DOMContentLoaded；loading="lazy"对其完全无效，实测100个20KB Data-URI可使解析耗时增加300ms+。
海量 Data-URI 图片会显著拖慢 HTML 解析，不是“卡在渲染”，而是从 Tokenizer 阶段就开始阻塞 DOM 构建。
Tokenizer 阶段被超长 base64 字符串拖垮
浏览器解析 HTML 时，先用 Tokenizer 把字节流切分成 token；而一个 <img src="data:image/png;base64,iVBOR..."> 标签，其 src 值可能长达数 KB～MB，直接生成超长文本 token。这带来三重压力：
- 字符串拷贝与内存分配开销剧增，V8 的 StringTable 和临时缓冲区占用快速上升
- Token 长度超 64KB 时，Chromium 内部可能触发缓冲区重分配 + GC 暂停
- DOM 构建被阻塞，
DOMContentLoaded明显延迟，首屏内容“迟迟不出现”
实测：100 个 20KB Data-URI <img> 标签，在中端 Android 设备上可使 HTML 解析耗时增加 300ms+。
loading="lazy" 对 Data-URI 完全无效
很多人加了 loading="lazy" 就以为图片能“懒加载”，但这是错觉——Data-URI 不走网络请求，浏览器在 Tokenizer 解析到该标签时，就必须立即创建图像解码上下文。
立即学习“前端免费学习笔记（深入）”；
-
loading="lazy"只控制fetch阶段，对内联src值无意义 - 哪怕
display: none、包裹在<template>里，或位于页面底部，只要标签被解析进 DOM，解码就已启动 - 服务端注入的调试注释（如
<!-- DEBUG: ... -->）若含大量 base64，也会被同样对待
如何快速识别和拦截高风险 Data-URI
不能等用户打开页面才发现问题。应在解析前做轻量预检：
- 用正则粗筛高危模式：
/data:image\/[a-z]+;base64,[A-Za-z0-9+/]{10000,}/，命中即拒绝或截断 - 检查响应头：
Content-Type必须是text/html或application/xhtml+xml，否则跳过解析 - 设长度兜底：
ContentLength > 1048576（1MB）时主动终止读取，防内存爆涨 - 禁用 Gumbo 的
GUMBO_OPTION_PARSE_IMPLICIT_END_TAGS，避免坏结构引发过度推测补全
真正难处理的不是“能不能放”，而是“什么时候让浏览器开始处理它”——Data-URI 一旦写死在 HTML 里，时机就彻底失控了。
