onerror无限循环的根本原因是备用图也404时事件持续触发：加载失败→onerror执行→新src加载又失败→再次触发onerror，形成死循环；必须用this.onerror=null紧接赋值后立即切断，且推荐使用base64 SVG内联占位图彻底规避路径风险。
onerror无限循环的根本原因是什么
浏览器在 img 的 src 加载失败后触发 onerror，但如果新赋值的 fallback 图（比如 this.src = 'fallback.png'）也 404，它会再次触发同一事件——不是“重试一次”，而是无终止地重复：加载 → 失败 → 触发 → 赋值 → 加载 → ……最终页面卡顿、内存飙升，DevTools 可能直接崩溃。
这不是浏览器 Bug，而是事件机制的自然行为。只要没主动切断，它就一直响应。
委托处理必须用 this.onerror=null 切断链路
委托的核心动作只有一条：this.onerror=null，且必须紧接在 this.src=... 赋值之后，中间不能有异步、不能换行、不能依赖外部函数。
- 正确写法：
onerror="this.src='/img/placeholder.svg'; this.onerror=null;" - 错误写法：
onerror="this.src='fallback.png'"（缺切断，必循环） - 错误写法：
onerror="fallbackHandler()"（函数未定义或执行失败，事件静默失效） - 错误写法：
onerror="this.onerror=null; this.src='...'"（顺序颠倒，切断早于赋值，fallback 不生效）
动态插入的 img 怎么安全绑定 onerror
用 document.createElement('img') 创建后才加 onerror，大概率来不及——DOM 插入瞬间就可能完成请求并失败，事件早已丢失。
立即学习“前端免费学习笔记（深入）”；
- 必须在插入前绑定：
const img = document.createElement('img'); img.onerror = () => { img.src = 'data:image/svg+xml;base64,...'; img.onerror = null; }; - 更稳妥的是全局捕获：用
document.addEventListener('error', e => {...}, true)（true表示捕获阶段），再通过e.target.tagName === 'IMG'和dataset标记过滤 - 务必加防重标记：
if (!e.target.dataset.fallbacked) { e.target.dataset.fallbacked = 'true'; ... }，否则多个监听器或多次插入可能重复触发
为什么 base64 占位图是委托最稳的 fallback
所有路径类 fallback 的风险都来自“第二次网络请求”——而 base64 是内联数据 URI，不发请求，彻底绕过 404、CORS、路径解析错乱等问题。
- 推荐用最小 SVG 占位：
data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iI2ZmZiIvPjwvc3ZnPg== - 不要用 PNG base64（体积大），也不要拼错 MIME 类型（如写成
image/svg而非image/svg+xml） - 服务端渲染时，若无法预知图片是否可用，直接把 base64 写进初始
src，比空src+ JS 注入更可靠
真正难的不是写对一行 onerror，而是确保 fallback 图自身绝对可达——路径错、大小写错、CDN 缓存旧地址、相对路径被 base URL 带偏……这些细节一旦漏掉，this.onerror=null 就成了“假切断”，循环照旧发生。
