onerror无限循环的典型表现是页面卡顿、内存飙升、DevTools崩溃或图片闪烁留白；根本原因是fallback图src也404且未切断监听，导致持续加载失败再触发onerror。

onerror 无限循环的典型表现是什么

页面卡顿、内存占用飙升、DevTools 偶尔崩溃，或图片反复闪烁后留白——这些不是“加载慢”，而是 onerror 在重试 fallback 图时不断触发自身。根本原因是：fallback 图的 src 也 404（或返回非图片内容），但没切断事件监听，导致浏览器持续尝试加载、失败、再触发 onerror。

怎么快速验证是否已陷入循环

打开 DevTools → Network 面板，勾选 “Disable cache”，然后刷新页面；观察对应图片请求是否出现**连续多个相同 URL 的 404（或 200 空响应）**。重点看：

• 请求次数是否 >1 次（尤其同一 fallback 路径重复出现）
• 响应 status 是不是 404 / 500 / 0（跨域拦截可能显示为 (failed) 或 0）
• Preview 标签页是否为空，或显示 HTML 错误页（如 Cloudflare 502）
• Console 是否有 RangeError: Maximum call stack size exceeded 或大量重复报错

验证 onerror 是否被正确切断的三步检查法

别只信代码写了 this.onerror=null，要确认它真被执行了：

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

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

下载

• 在 onerror 内加 console.log('onerror fired', this.src)，看控制台是否只打印一次（若多次，说明 this.onerror=null 没生效或写错位置）
• 用 getEventListeners(this)（在 Console 中执行）查该 元素是否还有 error 监听器（返回空数组才安全）
• 手动把 fallback 图路径改成一个明显不存在的地址（如 /xxx/missing.svg），刷新后观察是否仍触发 log 或网络请求——如果不再触发，说明切断成功

为什么有时 onerror 根本不触发，却误以为是“循环”

真正卡死的循环其实少见，更多是「以为降级了，其实什么都没发生」。以下情况 onerror **压根不会进入**，但开发者常归因为“循环没断”：

• src 为空、src="" 或 src=" "：浏览器不发请求，不触发 onerror
• 跨域图未加 crossorigin 属性：控制台报 Blocked by CORS policy，但 onerror 静默失效
• CDN 返回 200 + HTML 错误页（如 404 重定向到 /404.html）：状态码不是错误，onerror 不触发
• 图片文件头完好但数据截断（如 90% 的 JPEG）：部分浏览器不触发，行为不一致

这些场景下，你得换思路：用 fetch() 预检（需同域或 CORS）、或改用 + 可靠 作为兜底载体——onerror 只管“请求发出后失败”，不是万能钩子。

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