onerror无限循环的根源是浏览器直接触发机制无去重计数，防循环需用dataset标记状态、提前绑定事件、fallback用base64内联SVG确保可靠。
onerror无限循环的根源在哪
根本不是代码写得不够“智能”，而是浏览器对 onerror 的触发机制很直接：只要 src 加载失败，就执行属性里的 JS；如果新 src 又失败，它会再进一次——没有自动去重、没有内置计数、不看上下文。你写的 onerror="this.src='fallback.png'" 看似一行，实则埋了递归炸弹。
批量防循环必须用 dataset 打标
靠 this.onerror=null 能防单图死循环，但批量处理时容易漏掉动态插入的、或服务端渲染后 JS 再接管的图片。真正稳的方案是统一用 dataset 标记状态：
-
onerror里先检查this.dataset.fallbacked是否已存在，没有才换图 - 换图后立刻设
this.dataset.fallbacked = 'true'，而不是清空onerror - 这样即使同一张图被多个逻辑（比如全局监听 + 内联 onerror）同时捕获，也只降级一次
- 示例：
动态插入的图片 onerror 绑定时机很关键
用 document.createElement('img') 创建后，再赋值 onerror 是无效的——错误可能在 src 赋值瞬间就发生了，而事件监听还没挂上。
- 必须在设置
src之前，就完成onerror绑定 - 推荐写法：
const img = new Image(); img.onerror = () => { /* 降级逻辑 */ }; img.src = url; - 如果要用内联风格（比如 SSR 输出），就得确保 HTML 里已带完整
onerror，不能依赖 JS 后续补 - 框架中（如 Vue）用
@error.once或ref+$nextTick，本质也是把绑定提前到渲染前
fallback 图本身不可信，就别走路径依赖
90% 的批量循环问题，最后都指向同一个事实：你写的 fallback.png 在某个环境里压根不存在。相对路径错、CDN 未同步、大小写敏感、file:// 协议拦截……全是静默失败源。
- 最省心的 fallback 是 base64 内联 SVG：
data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iI2ZmZiIvPjwvc3ZnPg== - 所有批量场景（尤其是构建产物、微前端子应用）优先用这种，彻底绕过路径解析和跨域
- 如果非要用外部 fallback 图，路径必须是绝对路径（
/static/fallback.jpg），且部署前人工验证该 URL 能在浏览器地址栏直接打开
真正难的不是写几行降级代码，而是让每一张图的 fallback 都落在一个确定、可测、无副作用的位置。路径、标记、时机，三者只要一个松动，批量处理就会在某个角落悄悄崩掉。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
