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:// 协议拦截
• 动态插入的 必须在 appendChild() 前绑定 onerror，否则首次加载失败时事件已错过，后续再设 onerror 无效

画廊组件中容易被忽略的陷阱

画廊往往批量渲染图片，这时单靠内联 onerror 极易失控：

• 内部的 不是“可选 fallback”，而是强制渲染载体——如果它的 src 也 404，整个 就只剩 alt 文本，onerror 只会作用于这个 ，不感知上面所有 的失败
• 懒加载场景下，loading="lazy" 和 onerror 共存时，若 src 初始为空或为占位图，而 data-src 后续注入失败，onerror 可能根本不会触发（因为初始 src 没发请求）
• 使用 figure 封装画廊项时，若 被 display: none 或 visibility: hidden 包裹，Safari 和部分 WebView 会跳过加载，onerror 也不会执行

快速定位哪张图在循环

不用逐行翻 HTML，打开控制台直接运行：

使用华数设计生成高保真HTML原型、演示文稿、动画和设计评审

使用经过文档化的设计技能，从真实的品牌或项目背景中生成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 图必须独立托管、零依赖，不能和主图共用同一套路径逻辑或后端服务。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！