onerror死循环源于未及时禁用事件处理器，正确写法必须在赋值src后立即执行this.onerror=null；fallback资源须绝对路径或base64；动态图片需插入前绑定带重试计数的onerror。
onerror死循环根本不是“写没写”的问题，而是“断没断”——不加 this.onerror=null 就等于没写。
为什么onerror一换图就卡死
浏览器对 onerror 的处理非常严格：它只触发一次，但不会阻止你手动再次赋值 src；如果新 src 也 404，加载失败后不会再次进入 onerror，而是静默失败——此时你看到的“卡死”，其实是内存持续增长、DevTools 崩溃、标签页无响应的真实表现。
常见错误链：src="a.jpg" → 404 → 进入 onerror → this.src="fallback.png" → fallback.png 也 404 → 浏览器不再触发 onerror，但 JS 仍在尝试渲染、重绘、重排，CPU 拉满。
- 绝对不能写成
onerror="this.src='fallback.png'"（缺this.onerror=null） - 不能把
this.onerror=null放在后面或另起一行（执行顺序错，仍可能触发一次） - 不能用函数调用如
onerror="handleError(this)"而函数未定义——整个事件处理器解析失败，onerror彻底不生效
onerror 正确写法必须带分号和顺序
唯一稳定、可直接复制粘贴的内联写法是：
立即学习“前端免费学习笔记（深入）”；
<img src="icon.webp" onerror="this.src='/assets/placeholder.svg'; this.onerror=null;" alt="图标">
注意三点：
-
this.src必须指向一个真实可用的资源：推荐用绝对路径（如/assets/placeholder.svg）或 base64 内联（data:image/svg+xml;base64,...），彻底规避路径解析和 CDN 故障风险 -
this.onerror=null必须跟在赋值后、同一语句内，用分号隔开；不能换行，不能包裹在 if 或函数里（除非你确保该函数一定存在且执行无误） - 动态插入的
<img alt="HTML怎么防止占位图onerror死循环" >元素，onerror必须在appendChild()前绑定，否则首次错误已发生，事件监听器永远收不到
想多试几次？得自己管状态，不能靠反复触发onerror
浏览器不会给你第二次 onerror，所以“重试 2 次”必须靠 JS 自己记次数。用 dataset 打标是最轻量可靠的方式：
<img src="photo.jpg" data-retry="0" onerror="const n = +this.dataset.retry; if (n < 2) { this.dataset.retry = n + 1; this.src = n === 0 ? '/cdn/photo.jpg' : '/local/photo.jpg'; } else { this.src = 'data:image/svg+xml;base64,PHN2ZyB3...'; this.onerror = null; }" alt="HTML怎么防止占位图onerror死循环" >
关键逻辑：
- 用
data-retry记录当前是第几次失败，避免依赖 URL 字符串判断（易误判） - 最多允许两次换源：CDN 备份 → 本地相对路径 → 第三次直接上 base64 SVG，且立刻
this.onerror=null - 第三次不拼路径、不发请求，用
data:协议兜底，零失败可能
真正容易被忽略的点
很多人测的时候“好像没问题”，是因为开发环境 CDN 可用、路径全对；但上线后遇到本地双击打开 HTML、弱网、Nginx 配置漏了 /assets/ location、甚至微信公众号富文本上传时自动转义了引号——这些都会让 fallback 图瞬间失效，而你根本收不到任何报错。
最稳妥的做法不是“多写几个 onerror”，而是从源头掐断风险：所有占位图走 data:，所有生产 src 用绝对路径，所有动态图片在插入前统一绑定带计数的错误处理器。一旦漏掉其中一环，降级就变成幻觉。
