onerror触发死循环的根本原因是fallback资源加载失败后再次触发同一处理器，必须用this.onerror=null终止；fallback图须可访问、体积小、格式兼容，优先使用base64 SVG。
onerror 为什么会触发死循环
根本原因是备用资源（比如 fallback.png）本身也加载失败，浏览器会再次触发同一个 onerror 处理器，形成无限递归。不是代码写错了，而是 fallback 路径不可达——404、CORS 拦截、空响应体、甚至 Cloudflare 返回的 200 状态码 HTML 错误页，都可能导致二次失败。
此时页面可能卡顿、内存暴涨，标签页无响应，DevTools 的 Network 面板里能看到重复请求同一张 fallback 图。
必须写 this.onerror=null 才能终止
这是唯一可靠、跨浏览器生效的终止方式，不是“建议”，是硬性要求。
-
onerror属性必须内联书写，且赋值语句和切断事件绑定必须在一行、用分号隔开 - 顺序不能颠倒：
this.src='placeholder.svg'; this.onerror=null—— 先换源，再断链 - 绝对路径或 base64 最稳妥：
this.src='data:image/svg+xml;base64,...'; this.onerror=null - 避免使用相对路径 fallback，尤其在
file://协议下容易解析失败
备用图本身也要防失效
只防循环不防失效，等于没防。fallback 图必须满足三个条件：可访问、体积小、格式兼容。
立即学习“前端免费学习笔记（深入）”；
- 优先用内联 base64 SVG 占位图，彻底绕过网络请求
- 若用外部文件，确保其部署路径稳定，且服务器返回真实图片（非 200 状态的 HTML 页面）
- 可在本地起一个静态服务验证：
curl -I http://localhost:8080/fallback.svg看是否返回200 OK和Content-Type: image/svg+xml - 不要依赖 CDN 回源逻辑——CDN 返回兜底页时，
onerror不会触发
动态插入图片时怎么处理
用 JavaScript 动态创建 <img> 时，onerror 属性不会自动继承，也不能靠事件委托捕获，必须提前绑定。
- 推荐方式：创建后立即设置
img.onerror = function() { this.src = '...'; this.onerror = null; }; - 避免用
addEventListener('error', ...)，它无法阻止默认行为，也不保证只触发一次 - 如果批量插入，建议封装成函数，统一注入 fallback 逻辑和切断动作
- 注意：Vue/React 等框架中，
onerror是属性而非事件，需通过v-on:error或onErrorprop 透传，并在回调里手动切断
this.onerror=null，或者 fallback 路径没压测过，就等于埋了个定时炸弹。 
