onerror无限循环主因是未清空src、缺失重试计数及路径隔离；安全方案需绑定唯一data-retry-key、每次重试前设src=''、用dataset记录次数并校验备用地址索引。
onerror 循环不是浏览器行为，而是开发者误写重试逻辑导致的无限请求 —— 核心问题在于没做重试计数、没清空 src、没隔离失败路径。
为什么 onerror 会陷入无限循环
常见错误是直接在内联 onerror 里改 this.src，比如：onerror="this.src='fallback.png'"。浏览器发现新 src 仍加载失败，再次触发 onerror，形成死链。
- 浏览器对同一 URL 的 404 响应可能被内部缓存，重复赋值不触发新请求，但某些场景（如动态路径拼接）会真实发起多次请求
- 没清空
this.src = ''就赋新值，部分旧版 Chromium 会跳过加载 - 多个
<img>共享同一段内联脚本，this指向错乱，A 图失败却去重试 B 图的 URL
如何安全实现单次 fallback 或有限重试
关键不是“阻止循环”，而是“让每次重试都可判定、可终止”。必须绑定唯一标识 + 路径级计数 + 清空前置动作。
- 给每个
<img>加data-retry-key="avatar-123"，对应备用路径存在const fallbackMap = { 'avatar-123': ['cdn-a/123.jpg', 'cdn-b/123.jpg'] } - 重试函数中先执行
el.src = ''，再赋新值，避免浏览器跳过请求 - 用
el.dataset.retryCount = (parseInt(el.dataset.retryCount) || 0) + 1记录当前元素已尝试次数 - 检查索引是否超出备用数组长度：
if (index >= fallbackMap[key].length) return
动态创建 img 时 onerror 绑定必须用 addEventListener
内联 onerror 在 document.createElement('img') 后立即设置，但节点尚未插入 DOM，事件可能在绑定前就已触发；且字符串拼接易引入作用域污染。
- 正确写法：
img.addEventListener('error', handleImgError, { once: true })，{ once: true }防止多次绑定 -
handleImgError内通过e.target取到当前失败元素，无需依赖this - 不要在回调里调
e.target.setAttribute('onerror', ...)—— 这会覆盖原绑定，且无法清除
真正容易被忽略的是：重试逻辑必须和资源加载前的状态建立绑定。等 onerror 触发了再临时生成 fallback 列表，或靠 class 名查兄弟节点找备用地址，DOM 一变就全断。可靠方案只有一条：data-retry-key 必须在 src 首次赋值前就写好，且和后端返回的资源元数据对齐。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
