Base64图片onerror死循环根源在于fallback Base64字符串解析失败（如MIME错误、空格、编码损坏）导致新src仍触发onerror；防住关键：onerror中必须立即执行this.onerror=null，且优先用精简可靠的base64 SVG而非PNG/JPEG。
Base64图片onerror死循环的根源在哪里
不是Base64本身出错，而是onerror试图用另一个Base64兜底时，字符串写错（比如末尾多空格、MIME类型拼错为image/jpg）、或编码损坏导致浏览器解析失败——这时新src仍触发onerror，形成无限重试。内存飙升、标签页无响应是典型表现。
怎么写onerror才能防住Base64兜底失败
必须切断事件链，且避免二次解析风险：
- 写死
this.onerror=null，顺序不能颠倒：onerror="this.src='data:image/svg+xml;base64,PHN2Zy...'; this.onerror=null;" - 优先用SVG而非PNG/JPEG Base64：体积更小、无解码失败风险、天然支持透明背景
- 绝对不要在
onerror里拼接字符串或调用函数——onerror="this.src=generateFallback()"一旦generateFallback未定义，错误被吞，原图失败信号丢失 - 验证Base64字符串有效性：粘贴到DevTools Console执行
new Image().src = 'data:...'，看是否报net::ERR_INVALID_URL
动态插入的img如何安全绑定Base64 fallback
直接appendChild()后再赋值onerror大概率失效——错误在DOM挂载瞬间就已触发，事件监听器还没绑上。
- 创建后立即绑定：
const img = document.createElement('img'); img.onerror = () => { img.src = 'data:image/svg+xml;base64,...'; img.onerror = null; }; - 或用全局捕获（推荐）：
document.addEventListener('error', e => { if (e.target.tagName === 'IMG' && !e.target.dataset.handled) { e.target.dataset.handled = '1'; e.target.src = 'data:image/svg+xml;base64,...'; } }, true); - 确保
dataset.handled标记只设一次，防止同一张图被多次替换
Base64 fallback为什么有时“看起来成功”却实际不可靠
它绕过了网络请求，但引入了新瓶颈：HTML体积膨胀、解析阻塞、无法独立缓存。真正容易被忽略的是——
立即学习“前端免费学习笔记（深入）”；
- 服务端渲染（SSR）时，若Base64生成逻辑依赖客户端环境（如Canvas跨域未设
crossOrigin），服务端产出的data URI可能无效 - Lighthouse会把大Base64标为“enormous network payload”，首屏加载时间直线上升
- 修改图片后必须重新编码+替换全部硬编码字符串，没有缓存更新机制，极易遗漏
