onerror无限循环的根源在于备用图路径也失败时浏览器会反复触发该事件，必须每次赋值this.src后立即执行this.onerror=null来切断事件链，否则将导致内存暴涨、页面卡死甚至devtools崩溃。
onerror无限循环的根源在哪
浏览器对 onerror 的触发非常“诚实”：只要某次图片请求失败（404、500、网络中断、损坏文件），就进一次 onerror；而你在里面改了 this.src，如果新地址又失败，它会再进一次——没有自动去重、没有内置计数、不关心你是不是已经试过三次。栈溢出、标签页卡死、DevTools 崩溃，都是真实发生过的现象。
关键不是“要不要防”，而是“不防就崩”。this.onerror = null 不是锦上添花，是每次赋值 this.src 后必须立刻执行的动作。
多图场景下怎么避免每张都写一遍重复逻辑
内联写法虽可靠，但 10 张图手写 10 次 onerror="this.src='fallback.png'; this.onerror=null;" 易错且难维护。更实际的做法是：
- 服务端渲染或构建时统一注入：用模板引擎（如 EJS、Nunjucks）或构建插件（如 webpack-html-plugin）自动给所有
<img>补上标准onerror属性 - 若用 JS 动态插入图片，优先创建后立即绑定：
const img = new Image();<br>img.onerror = () => {<br> img.src = '/assets/placeholder.svg';<br> img.onerror = null;<br>};<br>img.src = originalSrc; - 禁止用
addEventListener('error', ...)替代内联写法——Safari 旧版、部分 WebView 中它根本不会触发
fallback 图自己也挂了怎么办
这是最常被忽略的“降级链断裂”点。路径写错、相对路径解析失败、CDN 回源异常，都会让 fallback 图二次失败。
- 绝对路径优于相对路径：
this.src = '/static/fallback.png'比this.src = 'fallback.png'更可控 - 小图直接 base64 内联：
this.src = 'data:image/svg+xml;base64,PHN2Zy...'，彻底绕过 HTTP 请求环节 - 加一层路径守卫（可选）：
onerror="if (!this.src.includes('fallback')) this.src='/fallback.svg'; this.onerror=null;"，防止 fallback 图再触发自身
为什么全局 document.error 监听不适合多图降级
document.addEventListener('error', handler) 理论上能捕获所有错误，但它有个硬伤：无法区分是哪张图失败，也无法在事件里安全修改 event.target.src（因为此时图片 DOM 可能尚未完全挂载，或已被移除）。更麻烦的是：
-
<source></source>元素不支持直接改src，只能靠兜底<img> - 多个动态插入的
<img>共享同一监听器时，容易因状态未隔离导致 fallback 错配 - 无法保证执行顺序：JS 还没加载完，首屏图片已触发失败，内联
onerror是唯一能覆盖这个窗口期的方式
真正需要全局监听的，只有一种情况：你无法控制 HTML 输出（比如 CMS 渲染的富文本内容），此时才用它做兜底补救，而非主力方案。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
