onerror无限循环的根本原因是备用图加载失败触发二次onerror，形成逻辑闭环；必须立即执行this.onerror=null阻断，推荐内联写法onerror="this.src='/img/placeholder.svg'; this.onerror=null;"，动态插入图片需提前绑定事件或用dataset标记状态防重试。
onerror无限循环的根源是什么
根本原因不是代码写错了，而是备用图本身也加载失败——浏览器会再次触发 onerror，新 src 再次 404，事件反复执行，内存持续增长，最终页面卡死或崩溃。这不是兼容性问题，而是逻辑闭环缺失。
必须写成 this.onerror = null 才安全
这是硬性操作，不是可选项。只写 this.src = 'fallback.png' 就像打开一个没锁的门，错误会反复进门。
-
onerror="this.src='/img/placeholder.svg'; this.onerror=null;"是唯一推荐的内联写法，分号不能省，顺序不能颠倒 -
this.onerror=null必须紧接在赋值之后，否则中间若有 JS 报错或异步延迟，仍可能触发第二次 - 绝对路径优先：用
/img/placeholder.svg而非./placeholder.svg，避免 base URL 解析偏差导致二次 404
动态插入的 img 元素怎么防循环
这类元素最容易漏掉防护，因为首次加载失败发生在 appendChild() 之后，内联 onerror 来不及绑定。
- 必须在插入 DOM 前就绑定事件：
img.addEventListener('error', handleImageError) - 或用 dataset 标记状态：
onerror="if (!this.dataset.fallbacked) { this.dataset.fallbacked = '1'; this.src = 'data:image/svg+xml;base64,...'; }" - 推荐 fallback 图用内联 data URL，比如
data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAi...，彻底规避路径和跨域风险
为什么 dataset.loaded 比 this.onerror=null 更可靠
在复杂场景（如 SSR + hydration、框架 re-render）下，this.onerror=null 可能被重置，而 dataset 是持久属性，状态更可控。
- 每次进入
onerror先检查if (this.dataset.retryCount && parseInt(this.dataset.retryCount) >= 2)，到上限就不再换源 - 第 3 次直接设为透明占位图：
this.src = 'data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw=='，并移除事件监听 - 服务端返回的 fallback 图（如
/img/missing?text=404）必须确保 Nginx/Apache 明确配置该路径，不能依赖前端兜底
真正容易被忽略的是：本地开发时双击打开 HTML 文件，90% 的“加载失败”其实源于 file:// 协议被浏览器拦截，此时 onerror 根本不会触发——得用 Live Server 启动，而不是靠修 JS 逻辑来掩盖环境问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
