onerror 触发后若未清除事件监听器或备用图仍失败，会引发无限递归调用，表现为页面卡死、内存飙升及 RangeError；可通过 Network 面板观察重复 404 请求或控制台连续打印 onerror fired 快速验证。
onerror 触发后怎么确认进了循环？
浏览器不会报“循环重定向”这种明确错误，但实际表现很典型：页面卡死、内存飙升、控制台出现 RangeError: Maximum call stack size exceeded 或 Stack overflow at line: 0。这不是 JS 语法错，而是事件链没切断导致的递归调用爆炸。
常见诱因就两个：
-
onerror里换的备用图地址（比如'fallback.png'）本身也返回 404 - 写了
this.src = 'fallback.png'却漏掉this.onerror = null，或顺序写反（比如先赋值再清空）
只要备用图不可达，哪怕只试一次，浏览器就会重新发起请求 → 失败 → 再触发 onerror → 再换图 → 再失败……无限下去。
如何用 DevTools 快速验证是否在循环？
打开 Chrome / Edge 的 Network 面板，勾选 “Disable cache”，然后刷新页面。观察图片请求列表：
立即学习“前端免费学习笔记（深入）”；
- 如果看到同一张 fallback 图（比如
/assets/placeholder.svg）被重复发出 5 次以上，且全部状态是404或Failed，基本就是循环了 - 点开任一失败请求，看 Response Headers 里有没有
X-Content-Type-Options: nosniff或Content-Type: text/html—— 这说明服务器返回了兜底 HTML 页面（比如 404 页面），而非真实图片，onerror会照常触发
更直接的办法：在 onerror 里加个简单计数器临时调试：
<img src="broken.jpg" onerror="console.log('onerror fired'); this.src='/missing.svg'; this.onerror=null;">
如果控制台连续打出几十条 onerror fired，说明 this.onerror=null 没生效，大概率是分号缺失、引号错位，或者备用图路径拼错了。
动态创建的 <img> 怎么避免首次就漏绑？
JS 创建图片时，onerror 必须在设置 src 之前 绑定，否则加载失败瞬间事件已过去，监听完全失效：
- ❌ 错误顺序：
img.src = url; img.onerror = handler; - ✅ 正确顺序：
img.onerror = handler; img.src = url;
更稳妥的做法是加 dataset 标记，防止多次降级：
img.onerror = function() {
if (!this.dataset.fallbacked) {
this.dataset.fallbacked = '1';
this.src = 'data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iI2ZmZiIvPjwvc3ZnPg==';
}
};真正容易被忽略的是：服务端返回 200 状态码但内容不是图片（比如 Nginx 默认 404 页面、CDN 的 HTML 错误页），此时 onerror 不触发，onload 却会执行——你看到的“加载成功”其实是假的。
