onerror死循环本质是资源加载失败反复触发事件，必须首次触发后立即置空onerror；内联写法应为onerror="this.src='fallback.png';this.onerror=null"，动态创建推荐addEventListener('error',handler,{once:true})。
onerror死循环的本质是事件反复触发
当 onerror="this.src='fallback.png'" 中的 fallback.png 也加载失败，浏览器会再次触发同一个 onerror，形成无限递归。这不是逻辑错误，而是 HTML 规范明确允许的事件行为——只要资源加载失败，就触发，不管之前是否已触发过。堆栈溢出、内存暴涨、DevTools 崩溃都是真实后果。
必须在首次触发后立即切断事件绑定
最直接有效的做法是：在赋值新 src 后，立刻置空 onerror 处理器。不能依赖“fallback 图一定存在”，而要默认它也可能失败。
-
onerror="this.src='fallback.png'; this.onerror=null"—— 内联写法唯一安全形式 - 动态创建
<img>时，优先用addEventListener('error', handler, { once: true })，{ once: true }是关键 - 若需复用 handler（比如统一日志或上报），handler 内第一行必须是
img.onerror = null，再做其他操作
带标识符的 fallback 更适合复杂场景
单纯防死循环靠 onerror=null 就够了；但当你有多个 fallback 路径（CDN 切换、本地兜底、降级为 SVG）、需要统计失败原因、或配合重试退避策略时，就得引入标识符。核心不是“加 ID”，而是让每个资源和它的 fallback 行为之间建立可追溯、不可歧义的绑定。
- 给
<img>加data-retry-key="user-avatar"，所有 fallback 逻辑（包括按钮、脚本、上报字段）都基于这个 key 查找 - 不要用
class或index定位目标元素——DOM 变动后立即失效 - 重试次数计数必须按
URL.pathname维度隔离，例如https://cdn-a.com/logo.png和https://cdn-b.com/logo.png视为不同路径，各自计数 - 备用路径数组长度就是最大重试次数，索引超出即终止，避免无意义轮询
容易被忽略的兼容性细节
看似简单的 this.onerror=null 在某些旧环境里并不保险：
立即学习“前端免费学习笔记（深入）”；
- IE8–9 不支持
addEventListener的{ once: true }，必须手动清空onerror - 动态插入的
<script>标签，其onerror必须在插入前绑定，否则可能在绑定完成前就已触发失败 -
onerror触发时，this.src可能是相对路径，直接拼接新域名会出错；应先用new URL(this.src, location.href)标准化 - 所有 fallback 资源（尤其是
fallback.png）建议走同域、不带查询参数、路径极简，降低二次失败概率
onerror=null 就万事大吉，真正麻烦的是 fallback 路径本身是否可靠、是否可追踪、是否与业务状态对齐。一个没被监控的 fallback，比没有 fallback 更危险。 
