onerror触发后直接替换src会因备用图失效再次触发，导致死循环；应立即置空onerror或标记已处理，并避免依赖其做首屏兜底，推荐用IntersectionObserver主动控制加载与容错。
onerror 触发后直接替换 src 会再次触发 onerror
这是最常见死循环根源：图片加载失败时，onerror 里把 src 换成备用图，但备用图也 404 或路径错误，就会再次触发 onerror，无限重试。
关键不是“要不要换图”，而是“换完必须阻止后续触发”。常见做法是清空 onerror 处理函数或标记已处理：
- 在
onerror回调里立即将this.onerror = null，确保只执行一次 - 或用
dataset标记：this.dataset.errorHandled = "true"，再加一层判断if (this.dataset.errorHandled) return - 避免在回调里重新赋值
src后不设防——哪怕你确信备用图存在，网络抖动或缓存异常也可能导致二次失败
用 loading="lazy" + onerror 组合时需注意 DOM 状态
异步加载常配合 loading="lazy"，但该属性会让浏览器延迟加载，而 onerror 只在加载尝试失败后触发。如果图片还没进入视口，onerror 根本不会执行；等它滚动进来才加载、才可能出错。
这意味着你不能假设页面一加载就完成容错处理。实操建议：
立即学习“前端免费学习笔记（深入）”；
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 不要依赖
onerror做首次渲染兜底——它不是同步事件，无法覆盖“加载前空白” - 若需首屏强保障，应提前用
<img>的src指向确定可用的占位图（如 base64 小图），再用 JS 异步换真实图，并单独监听换图后的失败 -
loading="lazy"和onerror是正交机制，别误以为 lazy 加载会“跳过 onerror”——它只是延迟触发时机
用 IntersectionObserver 替代 onerror 实现更可控的加载失败管理
真正需要异步加载+容错的场景，往往不只是“一张图挂了怎么办”，而是“哪些图该加载、加载失败后如何降级、是否重试、重试几次”。这时硬靠 onerror 已不够用。
推荐用 IntersectionObserver 主动控制加载流程，并将错误处理内聚在加载逻辑中：
- 观察元素进入视口后，用
fetch()或new Image()手动加载 URL，成功则设置img.src，失败则写入备用图并记录状态 - 可自然支持重试次数限制（比如最多试 2 次）、退避策略（延迟 500ms 再试）、上报错误（
console.error或打点） - 避免把所有逻辑塞进 HTML 的
onerror属性里——那无法维护重试逻辑，也无法做聚合统计
示例片段：
const img = document.querySelector('img[data-src]');
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
loadImage(img).catch(() => {
img.src = '/fallback.jpg';
img.classList.add('loaded-fallback');
});
observer.unobserve(img);
}
});
});
observer.observe(img);
服务端返回 200 但内容非图片也会触发 onerror
很多人忽略一点：onerror 不仅响应 404，还会响应任何非图像格式的响应体——比如 Nginx 返回 200 但内容是 “File not found” 文本，或 API 网关返回 JSON 错误页，浏览器解析失败，照样触发 onerror。
这种情况下，即使你写了 this.onerror = null，备用图仍可能因同样原因失败。所以：
- 检查服务器对图片路径的响应是否真为
Content-Type: image/*，用 DevTools 的 Network 面板确认 - 若用 CDN 或代理，确认它们没把 404 页面 fallback 成 200 + HTML
- 备用图 URL 最好独立部署、不走同一套路由逻辑，降低级联失败风险
