onerror无限循环的直接原因是备用图加载失败后事件未手动切断，导致重复触发；必须写成onerror="this.src='fallback.png'; this.onerror=null;"，且fallback图须用绝对路径或base64确保可访问。
onerror无限循环的直接原因是什么
浏览器不会自动阻止 onerror 重复触发——只要图片加载失败，且你没手动切断事件绑定，它就会一直执行。最常见场景是：this.src = 'fallback.png' 赋值后，fallback.png 本身也 404，于是再次进入 onerror，形成递归。内存暴涨、标签页卡死甚至崩溃都是真实后果。
必须写的防死循环代码结构
可靠写法只有一种，且顺序不能错：
-
this.src赋值必须在前，新地址要确保可访问（推荐用绝对路径或 base64） -
this.onerror = null必须紧接其后，中间不能有分号以外的字符 - 写成
onerror="this.src='placeholder.svg'; this.onerror=null;"是底线要求 - 如果备用图路径带查询参数（如
?v=1），需确认 CDN 或服务端能稳定返回 200 + 正确 MIME
动态插入图片时容易漏掉的关键点
通过 document.createElement('img') 创建的元素，onerror 属性必须在插入 DOM 前就设置好。否则，图片可能在 appendChild() 瞬间就开始加载并失败，而事件还没绑定上。
- 错误写法：
const img = document.createElement('img'); img.src = url; container.appendChild(img); img.onerror = handler; - 正确写法：
const img = document.createElement('img'); img.src = url; img.onerror = handler; container.appendChild(img); - 更稳妥方案：全局监听
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 标记比只靠 this.onerror=null 更保险
this.onerror = null 只能防住同一事件监听器的重复调用，但如果你在多个地方（比如框架指令、全局监听、内联属性）都绑了 onerror，就可能漏判。用 data-handled 或 data-retry-count 这类标记，能跨上下文统一控制降级次数。
立即学习“前端免费学习笔记（深入）”；
- 例如重试最多 2 次：
if (!this.dataset.retryCount) this.dataset.retryCount = '0'; const count = parseInt(this.dataset.retryCount); if (count - 注意：不要仅依赖
src字符串判断是否已降级（比如含fallback），有些 CDN 会自动重写 URL，导致误判
真正终结死循环，不在于“多加一层判断”，而在于每次赋值 src 后，立刻让这次错误处理失效——无论是靠 this.onerror=null，还是靠 dataset 标记，核心都是让下一次失败不再触发同一逻辑。这点一旦遗漏，再复杂的 fallback 链路都只是加速崩溃。
