onerror 会陷入死循环是因为备用图加载失败后再次触发同一事件，形成无限递归；根本解法是赋值后立即执行 this.onerror=null 切断后续触发。
onerror 事件写成 onerror="this.src='fallback.png'" 就一定会卡死——因为备用图再失败，会再次触发 onerror，形成无限递归，浏览器主线程被拖垮，标签页无响应。
为什么 onerror 会陷入死循环
根本原因不是事件本身有问题，而是错误处理逻辑没切断后续触发条件。当 src 加载失败时，onerror 执行；如果 fallback 图（比如 'fallback.png'）也 404 或路径错误，浏览器会再次触发同一 onerror，于是 this.src=... 又跑一遍，又失败，又触发……内存持续上涨，页面冻结。
- 这个循环不会被浏览器自动拦截，也不会报错到控制台
- 它不依赖 JS 异常，纯属 HTML 层级的事件重入
- 哪怕 fallback 是相对路径（如
./img/placeholder.jpg），只要当前上下文没配好 base URL，就极大概率失败
正确写法必须包含 this.onerror=null
唯一可靠解法是在赋值后立即解除绑定，让第二次失败不再触发事件。顺序和语法都不能错：
<img src="real.jpg" onerror="this.src='/assets/placeholder.svg'; this.onerror=null;" alt="HTML页面onerror死循环卡死怎么办？恢复正常跳出循环方法" >
-
this.onerror=null必须紧接在this.src=...后面，中间不能换行、不能缺分号 - 推荐用绝对路径或 base64 内联 SVG，彻底规避路径失效风险：
data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAi... - 不要用
javascript:void(0)或空字符串做 fallback，它们也会触发onerror
动态插入的 img 元素怎么防死循环
通过 JS 创建并插入的 <img alt="HTML页面onerror死循环卡死怎么办？恢复正常跳出循环方法" >，onerror 属性写在字符串里容易漏掉 this.onerror=null，更稳妥的是用事件监听器绑定，并确保只执行一次：
立即学习“前端免费学习笔记（深入）”；
const img = document.createElement('img');<br>img.src = 'dynamic.jpg';<br>img.addEventListener('error', function handler() {<br> this.src = 'fallback.svg';<br> this.removeEventListener('error', handler);<br>});<br>container.appendChild(img);
- 用
addEventListener+removeEventListener比内联属性更可控 - 必须传函数引用（不能是匿名函数），否则无法精准移除
- 如果图片是批量渲染（如列表），别在循环里重复定义 handler 函数，避免闭包堆积
alt 和 picture 不能代替 onerror 的兜底作用
alt 只在图片完全不加载时显示文字，不阻止白屏；<picture></picture> 中的 <img alt="HTML页面onerror死循环卡死怎么办？恢复正常跳出循环方法" > 是强制兜底，但它自己的 src 一旦失败，照样触发 onerror——所以它的 src 也必须指向高可用资源，比如 CDN 上的占位图或 base64。
-
<picture></picture>不是“多试几个格式就稳了”，它只管 source 切换，不管最终<img alt="HTML页面onerror死循环卡死怎么办？恢复正常跳出循环方法" >加载成败 - 服务端渲染首屏图片时，千万别把
src设为 JS 计算出来的路径，那等于放弃 HTML 层兜底能力 - 断网测试时，只有真正内联、无需网络请求的 fallback（如 base64）才能稳住页面不白屏
最易被忽略的一点：onerror 不响应 CORS 阻塞、空 src、或服务器返回 200 的兜底 HTML 页面——它只捕获网络请求层面的失败。如果你看到图片没显示但 onerror 没触发，先检查 Network 面板里请求是否真的返回了 404/500，而不是 200 + 错误内容。
