必须在onerror回调中设this.onerror=null或用data-error-handled标记已处理，否则fallback图再失败会无限触发；同时确保fallback路径真实可访问，防止死循环导致卡顿或崩溃。
onerror 事件触发后如何避免无限重试
直接在 img 标签里写 onerror="this.src='fallback.jpg'"，图片加载失败时会换图；但如果 fallback.jpg 也不存在，onerror 会再次触发，导致死循环。浏览器可能卡顿、报错或静默降级，这不是预期行为。
- 根本原因是：每次赋值
this.src都会触发一次新的资源加载尝试，失败就再进onerror - 必须在回调里「切断重试链」，最简单方式是清空
onerror或设为null - 不能只靠换 src —— 换了还得确保新地址一定可访问，否则白忙
用 data-* 属性标记是否已处理过错误
借助自定义属性（如 data-error-handled）做状态标记，比操作内联 onerror 更可控，尤其适合批量渲染或框架环境。
-
data-error-handled="true"表示已执行过降级逻辑，后续不再响应错误 - 在
onerror回调中先检查该属性，再决定是否执行 fallback - 兼容性好，所有现代浏览器都支持
datasetAPI 读写
<img src="broken.jpg"
data-fallback="placeholder.svg"
data-error-handled="false"
onerror="handleImageError(this)">handleImageError 函数内部应类似：
function handleImageError(img) {
if (img.dataset.errorHandled === 'true') return;
const fallback = img.dataset.fallback;
if (fallback) {
img.src = fallback;
img.dataset.errorHandled = 'true';
}
}为什么不能只靠 try/catch 捕获图片加载失败
try/catch 对 img.src 赋值无效 —— 图片加载是异步的，抛错不走 JS 异常流，而是触发 error 事件。这是 DOM 加载机制决定的，和 fetch 或 XMLHttpRequest 的错误处理逻辑完全不同。
立即学习“前端免费学习笔记（深入）”；
-
img.addEventListener('error', ...)和内联onerror是唯二可靠入口 - 动态创建
img元素时，必须在设置src前绑定error监听器，否则可能错过首次错误 - 服务端返回 404 不等于 JS 报错，它只是让浏览器派发一个
error事件
更健壮的 fallback 策略要考虑加载状态
单纯换一张图还不够：如果 fallback 图也加载慢或失败，用户看到的是长时间空白或二次错误。需要叠加 loading 状态提示和最终兜底。
- 初始状态可设
data-status="loading"，成功后改为"loaded"，失败后改为"failed" - 对关键图片，建议预加载 fallback 资源（用
link rel="preload"），降低二次加载失败概率 - 如果连 fallback 都不可用，应移除
src并插入占位文案，而不是留着一个持续报错的img标签
循环问题的本质不是语法错误，而是没把「错误处理」当成一次性的状态迁移 —— 只要没明确标记“这事结束了”，浏览器就会继续尝试。
