根本原因是浏览器规范行为：加载失败→触发onerror→换src→再请求→若新src仍404则重复触发，形成递归；必须用this.onerror=null立即阻断，且须写在this.src赋值后、分号不可省略。
onerror 无限循环的根本原因是什么
不是代码写错了，而是浏览器规范行为：图片加载失败 → 触发 onerror → 修改 this.src → 再次发起网络请求 → 若新地址也 404，就再次触发 onerror，形成递归调用。内存持续增长，轻则卡顿，重则标签页崩溃、报 Stack overflow at line: 0。
必须立刻执行 this.onerror = null 才能阻断
这是唯一可靠、跨浏览器生效的切断方式。关键点只有两个：
-
this.onerror = null必须写在修改this.src的同一行，且分号不能省略 - 顺序不能颠倒：先赋值
this.src，再执行this.onerror = null - 绝对不能只写
onerror="this.src='/fallback.svg'"—— 这是高发卡死写法
正确示例：onerror="this.src='/assets/placeholder.svg'; this.onerror=null;"
备用图路径不可靠是循环复现的主因
很多“已加 this.onerror=null 却仍卡死”的案例，问题出在备用图本身不可达。常见陷阱包括：
立即学习“前端免费学习笔记（深入）”；
- 用相对路径如
./fallback.png，实际解析后变成 404（尤其在路由嵌套或 SPA 中） - CDN 地址拼错、节点下线、未配置 fallback 域名
- 误把
alt当作视觉兜底——它不加载任何资源，也不阻止破图显示 -
<picture>中只写了<source>，但内部<img>的src指向了一个不存在的地址
推荐直接使用内联 base64 SVG：data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iI2ZmZiIvPjwvc3ZnPg==，彻底规避路径解析和 CDN 依赖。
动态创建的 <img> 怎么安全绑定 onerror
JS 创建的图片元素，onerror 必须在设置 src 之前绑定，否则首次加载失败时事件早已错过：
- ❌ 错误：先设
img.src = url，再img.onerror = handler - ✅ 正确：先
img.onerror = handler，再img.src = url，最后container.appendChild(img) - 更稳妥做法是加
dataset标记，防重复降级：if (!this.dataset.loaded) { this.dataset.loaded = '1'; this.src = '/fallback.svg'; }
全局监听（document.addEventListener('error', ...)）虽可捕获动态图片，但它不冒泡、Safari 支持差，且无法区分是图片还是脚本错误——对图片容错，内联 + 提前绑定仍是首选。
this.onerror=null，只要备用图返回非 200（哪怕只是 404 或 CORS 阻塞），循环就可能静默重启；而 onerror 本身对空 src、CORS 报错、服务器返回 200 的兜底页等场景完全不响应——这些都得靠其他手段补位。 
