onerror无限触发的根源是备用资源不可达，导致浏览器在换图后再次触发onerror，形成死循环；必须用this.src='fallback'; this.onerror=null;确保 fallback 可达且事件链闭环。
onerror无限触发的根源是什么
它不是代码写错了，而是备用资源本身不可达。浏览器加载原始 src 失败后进入 onerror，你换了个新 src，结果这个新地址也 404（或 CORS 阻塞、空字符串、file:// 协议等），浏览器再次触发 onerror——循环就此开始。内存暴涨、标签页无响应、甚至崩溃，都是这个链式重试导致的。
-
onerror只响应网络层失败（404/403/500），对空src、跨域被拦截、200 返回兜底页等情况完全沉默 - 所以“备用图挂了”才是真问题，不是“没写
onerror” - 常见错误路径：
src="user/123.jpg"→ 404 →onerror→ 换成"fallback.png"→ fallback.png 也 404 → 再进onerror
静态 img 标签怎么写才安全
必须同时满足三件事：换图、切断事件、确保 fallback 可达。缺一不可。
-
onerror属性中必须用分号连接两步：this.src='/assets/placeholder.svg'; this.onerror=null; -
this.onerror=null必须紧接在赋值之后，顺序不能颠倒 - fallback 路径推荐用绝对路径（如
/assets/placeholder.svg）或 base64 data URL（如data:image/svg+xml;base64,PHN2Zy...），避免相对路径因 base URL 变化而二次 404 - 别用 PNG/JPG 作 fallback——SVG 体积小、无渲染失败风险、天然透明背景
动态创建的 img 怎么绑定 onerror 不丢事件
插入 DOM 后再补 onerror 几乎必然失效：错误在 appendChild 瞬间就已触发，事件监听器还没挂上。
- 创建时立即赋值：
const img = document.createElement('img'); img.onerror = () => { img.src = '/fallback.svg'; img.onerror = null; }; - 或统一用捕获阶段全局监听（更可靠）：
document.addEventListener('error', e => { if (e.target.tagName === 'IMG' && !e.target.dataset.handled) { e.target.dataset.handled = '1'; e.target.src = 'data:image/svg+xml;base64,...'; } }, true); -
dataset.handled是防重复替换的关键，避免同一张图多次触发逻辑 - 全局监听必须加
true参数，否则无法捕获到动态插入元素的错误
为什么用 dataset 比单纯判 src 更稳
只靠 if (!this.src.includes('fallback')) 很脆弱：路径可能含查询参数、CDN 域名不同、大小写不一致，甚至 fallback 图本身带 hash（fallback.a1b2c3.svg）就直接失效。
立即学习“前端免费学习笔记（深入）”；
- 推荐用
dataset打标：onerror="if (!this.dataset.loaded) { this.dataset.loaded = '1'; this.src = '/fallback.svg'; }" - 这个标记是 DOM 属性，不受 URL 解析影响，也不依赖字符串匹配
- 它天然隔离状态：哪怕你后续手动改了
src，只要dataset.loaded已存在，就不会再进分支 - 对 SSR 渲染或服务端预设 fallback 的场景也兼容，不需要 JS 初始化就能生效
真正卡死页面的从来不是“要不要兜底”，而是兜底动作是否闭环。只要备用图路径没验证过、this.onerror=null 漏写了、或者动态插入时机没卡准，内存就可能在几秒内飙到几百 MB。这些点没法靠“试试看”绕过去，必须每处都按闭环逻辑来。
