onerror无限循环的典型表现是页面卡顿、内存暴涨、控制台狂刷错误乃至标签页无响应；根本原因是备用图本身404或路径错误，导致onerror反复触发形成死链。
onerror 无限循环的典型现象
页面卡顿、内存暴涨、控制台疯狂打印错误，甚至浏览器标签页无响应——这是 onerror 循环最直接的表现。根本原因不是“图片没加载出来”，而是备用图（fallback）本身也 404 或路径错误，导致 onerror 被反复触发。浏览器不会自动阻止这个过程，它会一直尝试加载失败的 src，再进 onerror，再换图，再失败……形成死链。
必须检查的三个硬性条件
只要漏掉其中任意一项，onerror 就大概率进入循环：
-
this.onerror = null必须写在赋值this.src之后，且中间不能有分号以外的语句（比如注释或空格）；错误写法：onerror="this.src='fallback.png'; // 注释; this.onerror=null;" - 备用图路径必须真实可访问：用绝对路径（如
/static/placeholder.svg）或内联 base64（如data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAi...），避免相对路径拼错或本地file://协议拦截 - 动态插入的
<img alt="HTML画廊组件出现onerror循环如何排查" >必须在appendChild()前绑定onerror，否则首次加载失败时事件已错过，后续再设onerror无效
画廊组件中容易被忽略的陷阱
画廊往往批量渲染图片，这时单靠内联 onerror 极易失控：
-
<picture></picture>内部的<img alt="HTML画廊组件出现onerror循环如何排查" >不是“可选 fallback”，而是强制渲染载体——如果它的src也 404，整个<picture></picture>就只剩alt文本，onerror只会作用于这个<img alt="HTML画廊组件出现onerror循环如何排查" >，不感知上面所有<source></source>的失败 - 懒加载场景下，
loading="lazy"和onerror共存时，若src初始为空或为占位图，而data-src后续注入失败，onerror可能根本不会触发（因为初始src没发请求） - 使用
figure封装画廊项时，若<img alt="HTML画廊组件出现onerror循环如何排查" >被display: none或visibility: hidden包裹，Safari 和部分 WebView 会跳过加载，onerror也不会执行
快速定位哪张图在循环
不用逐行翻 HTML，打开控制台直接运行：
立即学习“前端免费学习笔记（深入）”；
Array.from(document.images).filter(i => i.naturalWidth === 0 && i.src).forEach(i => console.warn('疑似失败:', i.src, 'onerror:', i.onerror))
这条命令会列出所有“假图”（未成功解码）且带 onerror 绑定的元素。重点看输出里 onerror 是否仍为函数体（说明没被置空），以及 src 指向的 fallback 地址能否在新标签页中直接打开。
复杂点在于：循环可能不发生在首屏，而是用户滚动后懒加载的图片；也可能只在特定 CDN 节点故障时复现。所以 fallback 图必须独立托管、零依赖，不能和主图共用同一套路径逻辑或后端服务。
