onerror死循环表现为页面卡顿、内存持续上涨、DevTools无响应或标签页崩溃；确认方式是Network面板见同一fallback图多次404，或Console频繁打印对应URL的加载失败日志。

onerror死循环的典型表现和确认方式 页面卡顿、内存持续上涨、DevTools 偶尔无响应，甚至标签页崩溃——这些不是 JS 执行慢，而是 onerror 在反复触发。最直接证据：Network 面板里看到同一张 fallback 图被连续发起多个 404 请求；或者控制台频繁打印「Failed to load resource」且 URL 明显是降级后的地址（比如 fallback.png）。

关键判断点：onerror 只在图片请求返回非 200（如 404/403/500）时触发一次，但如果新 src 也失败，它会再次进入该 handler——这就是死循环起点。

为什么this.onerror=null必须写在赋值后且不能省略 这不是“建议”，是浏览器行为决定的硬性要求。不加这句，只要备用图路径不可用，就会无限重试：

• onerror="this.src='fallback.png'" → 备用图 404 → 再次触发 onerror → 再次设 src → 循环
• onerror="this.src='fallback.png'; this.onerror=null" → 备用图 404 → 触发一次 → 立即移除监听 → 不再重复
• 顺序不能颠倒：this.onerror=null 必须紧接在 this.src=... 后，中间不能有异步操作或条件分支

常见错误写法：onerror="if (!this.src.includes('fallback')) this.src='fallback.png'" —— 缺少 this.onerror=null，照样死循环。

怎么快速定位是哪张图在循环 不用逐行翻 HTML，用 Network + Console 联合排查：

• 打开开发者工具 → Network → 过滤 Img，复现加载过程，找重复出现的 404 请求，记下它的完整 Request URL
• 回到 Elements 面板，Ctrl+F 搜索该 URL，找到对应 标签
• 检查它的 onerror 属性是否含 this.onerror=null；若没写，或写成了 this.onerror = null（少了 = 右侧分号），就是根源
• 在 Console 执行 document.querySelectorAll('img').forEach(i => i.addEventListener('error', () => console.log('error on:', i.src)))，看是否有多余 error 日志涌出

注意：如果 fallback 图用了相对路径（如 ./fallback.png），而当前页面 URL 是 /admin/user/，实际请求会变成 /admin/user/./fallback.png，服务端很可能 404——这种路径错位比代码逻辑更常引发循环。

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

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

下载

备用图路径本身不可靠时怎么办 别赌路径拼对了，优先用内联 base64 占位图，彻底规避网络请求失败风险：

• 把 SVG 占位图转成 base64：data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iI2ZmZiIvPjwvc3ZnPg==
• 写进 onerror 时直接用这个字符串，确保最后一次降级绝对不发请求：onerror="this.src='data:image/svg+xml;base64,...'; this.onerror=null"
• 如果必须用外部 fallback 图，务必验证它在浏览器地址栏中能直接打开并返回 200 + 正确 content-type（image/png 或 image/svg+xml）

真正棘手的不是写错一行代码，而是 fallback 图本身又依赖另一层路径解析、CDN 配置或大小写敏感——这些细节在本地 file:// 下完全不暴露，一上生产就循环爆炸。

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