onerror循环触发的典型现象是图片或脚本加载失败后，因浏览器缓存404响应、未清空src、无状态隔离，导致fallback URL也失败时陷入无限重试，控制台反复报错、元素空白或闪烁。
onerror 循环触发的典型现象
图片或脚本加载失败时，onerror 回调里直接改 this.src 或 this.src，浏览器可能缓存了 404 响应，导致新赋值仍触发 onerror；更糟的是，若 fallback 图 URL 本身也加载失败，就会陷入无限重试循环——控制台反复打印错误，readyState 可能卡在 0，DOM 中该元素持续闪烁或空白。
为什么直接在 onerror 里改 src 会循环
根本原因有三层：
- 浏览器对已失败的资源 URL 有短时缓存（尤其 404），即使你改了
this.src，只要新值和旧值解析后指向同一地址（比如相对路径未标准化），它就跳过请求、直接再次触发onerror -
onerror是同步触发的，回调中若没做状态隔离，每次都会执行相同逻辑 - 没清空原始
src就赋新值，部分浏览器（如旧版 Safari）会忽略这次赋值，或把它当成无效变更
防抖式重试的实操写法
这不是加个 setTimeout 就行的事，得结合路径去重、清空源、状态标记三步走：
- 必须先设
e.target.src = ''，再赋 fallback 地址，强制浏览器发起新请求 - 用
new URL(e.target.src, location.href)标准化原始 URL，提取.pathname作为重试键，避免不同域名但同路径的重复计数 - 维护一个全局
retryMap = new Map()，以 pathname 为 key，记录当前重试次数；超过阈值（如 2 次）直接放弃，不进循环 - fallback 图 URL 必须提前预加载：
const fallbackImg = new Image(); fallbackImg.src = '/img/default.png';，否则第一次 fallback 也会白屏几百毫秒
示例关键逻辑：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
function handleImgError(e) {
const img = e.target;
const url = new URL(img.src, location.href);
const key = url.pathname;
const count = retryMap.get(key) || 0;
if (count >= 2) return;
retryMap.set(key, count + 1);
img.src = ''; // ⚠️ 必须清空
img.src = '/img/default.png';
}
动态元素必须用 addEventListener 绑定
内联写法如 onerror="handleImgError(this)" 在动态插入的 <img alt="HTML怎么通过防抖处理onerror循环触发" > 上极易失效：
- 元素插入 DOM 前，
onerror属性已存在，但此时 JS 还没执行，函数未定义 → 静默失败 - 多个元素共享同一段内联脚本时，
this可能指向错乱（比如被外层with语句劫持） - 无法做统一重试控制：你没法在插入前就给每个元素打上唯一
data-retry-key并关联到retryMap
正确方式是创建元素后立即绑定：
const img = document.createElement('img');
img.dataset.retryKey = 'user-avatar';
img.addEventListener('error', handleImgError);
container.appendChild(img);
真正容易被忽略的点：重试逻辑必须在资源首次加载前就准备好——不是等 onerror 触发了再初始化 retryMap 或预加载 fallback 图。晚一步，第一次失败就进不了防抖闭环。
