onerror 无限循环是因为图片加载失败触发 onerror，赋新 src 后再次失败又触发，形成递归；必须内联写 this.src='fallback'; this.onerror=null; 且 fallback 优先用 base64 SVG。

onerror 一写就卡死，根本不是语法错，而是备用图也 404，浏览器会反复加载、失败、再触发 onerror——必须用 this.onerror=null 立即切断事件链。

为什么 onerror 写了就无限循环？

浏览器对图片加载失败的处理是：请求失败 → 触发 onerror → 执行新 src 赋值 → 发起新请求 → 若仍 404，再次触发 onerror……形成递归。这不是 bug，是规范行为。

• 常见诱因：fallback.png 是相对路径（如 ./fallback.png），实际解析后 404
• CDN 地址拼错、节点故障，或用了未验证的临时 URL
• 误把 alt 当作兜底——它只显示文字，不触发任何加载
• 中 的 src 本身不可达，所有 失败后仍白屏

onerror 必须内联 + 立即切断

动态绑定 addEventListener('error', ...) 在 Safari 和旧 Edge 中基本不可靠；document.addEventListener('error') 也不捕获图片错误（事件不冒泡）。唯一稳定方式是内联写法，且顺序不能错：

• 先赋新 src，再立刻执行 this.onerror=null，分号不能省
• 错误写法：onerror="this.src='fallback.png'" → 高发卡死
• 正确写法：onerror="this.src='/assets/placeholder.svg'; this.onerror=null;"
• 推荐用 base64 SVG，彻底规避路径风险：data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iI2ZmZiIvPjwvc3ZnPg==

动态创建的 怎么防循环？

JS 创建的图片元素，onerror 必须在插入 DOM 前绑定，否则首次加载失败时事件已错过：

使用华数设计生成高保真HTML原型、演示文稿、动画和设计评审

使用经过文档化的设计技能，从真实的品牌或项目背景中生成HTML原生原型、幻灯片、动态演示、可视化图表和评审流程。

下载

• 不要这样：const img = new Image(); img.src = url; container.appendChild(img); img.onerror = handler;
• 要这样：const img = new Image(); img.onerror = handler; img.src = url; container.appendChild(img);
• 更稳妥做法是用 dataset 打标，避免重复降级：img.onerror = function() { if (!this.dataset.loaded) { this.dataset.loaded = '1'; this.src = '/fallback.svg'; } };
• 若需多级重试（CDN → 本地 → SVG），最多尝试 2 次，第 3 次直接设透明图并移除 onerror

里的 onerror 容易被忽略的点

不是“自动兜底容器”，它的 子元素才是最终 fallback 载体：

• 全部不匹配，浏览器会渲染 的最后一个子元素 —— 就是那个
• 这个 的 src 必须指向一个静态、无查询参数、能直接在地址栏打开的资源（如 /img/placeholder.jpg）
• 错误写法： → 旧浏览器发请求，后端可能返回 406 或损坏数据
• 服务端渲染时，首屏 的 src 应该是真实可访问的 URL，而非依赖 JS 后续注入

真正麻烦的从来不是“怎么写 onerror”，而是备用图是否真能加载成功——路径写错、CDN 故障、file:// 协议下绝对路径解析异常，都可能让 this.onerror=null 失效。最稳的兜底永远是 base64 SVG，它不依赖网络、不触发请求、不产生额外错误。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！