onerror触发后直接替换src会无限循环，因fallback图片加载失败会再次触发onerror；最稳妥解法是先置空onerror再赋值src，如this.onerror=null; this.src='placeholder.png'。
onerror 触发后直接替换 src 会无限循环
当 img 的 onerror 里只写 this.src = "fallback.jpg"，而 fallback 图片本身也加载失败时，会再次触发 onerror，形成死循环。浏览器可能卡顿、报错 RangeError: Maximum call stack size exceeded，或静默降级但反复请求失败资源。
根本原因是：没阻止错误源再次触发自身。必须在替换前确保新地址不会再次出错，或显式取消后续错误监听。
- 最稳妥做法是先清除
onerror处理函数，再赋值src - 也可以用标志位（如
data-loaded）避免重复执行，但需手动维护状态 - 不推荐用
setTimeout延迟赋值来“绕开”循环——只是掩盖问题，无法解决 fallback 本身失效的情况
用 this.onerror = null 切断循环最简单可靠
这是实际项目中最常用、兼容性最好（IE8+ 支持）的解法。在事件回调内第一行就置空 onerror，确保无论后续 src 是否成功，都不会再进这个函数。
<img src="avatar.jpg" onerror="this.onerror=null; this.src='placeholder.png'" alt="HTML列表图片加载失败时onerror循环如何处理" >
- 注意顺序：
this.onerror=null必须在this.src=...之前，否则仍可能触发第二次 - 如果 placeholder.png 也不存在，页面只会显示浏览器默认缺失图标，不会崩溃或重试
- 不要写成
this.onerror = function(){...}内再调用this.src—— 那又回到原点
Vue/React 等框架中别直接操作 this.onerror
在响应式框架里硬写 onerror 行内属性，会绕过数据流和生命周期，导致状态不同步、难以调试。比如 Vue 模板里写 @error="handleError"，但在 handleError 里又直接改 img.src 和 img.onerror，容易和响应式系统冲突。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 推荐方案：用计算属性或
ref控制src，错误时切换到备用 URL，并通过v-if或key强制重新挂载 img 元素 - React 中可用
useState存当前图片 URL，onError回调里setState(fallback)，并确保 fallback 是已知有效的本地资源（如 public 目录下的图） - 避免在事件里直接操作 DOM 属性（如
el.onerror），尤其用了 Suspense 或服务端渲染时，DOM 可能还没就绪
真正要防的不是循环，而是 fallback 也失效
很多人花时间 debug 循环，却忽略更关键的问题：你设的 fallback 图片路径是否真的存在？是否被构建工具忽略？是否跨域？404 的 fallback 会让 onerror 清除后依然显示空白。
- 检查网络面板，确认 placeholder.png 返回 200，而不是 404 或 302 跳转失败
- 静态资源尽量用相对路径或 public 目录下文件，避免走 webpack/vite 构建流程导致路径错乱
- 复杂场景可预加载 fallback 图：用
new Image().src = "placeholder.png"提前验证，但注意不要阻塞主逻辑
onerror 循环只是表象，根子在资源可靠性。先确保 fallback 100% 可用，再谈怎么安全切换。
