最常见根因是备用图路径也404导致无限循环；必须写成this.src='xxx'; this.onerror=null，顺序不可颠倒，推荐用base64占位图彻底规避路径风险。
onerror无限触发导致页面卡死的根因
最常见的情况是备用图路径也 404，浏览器加载 fallback.png 失败后再次进入 onerror，形成递归调用。内存持续增长，标签页可能无响应甚至崩溃。这不是浏览器 bug，而是逻辑缺失——onerror 本身不带防重机制，必须手动切断。
img 的 onerror 必须写成 this.src='xxx'; this.onerror=null
这是唯一可靠的基础写法，顺序和分号都不能错：
-
this.src赋新值后，必须紧跟着this.onerror = null，否则下一次失败仍会触发 - 不能写成两行或用逗号分隔，内联属性中换行或空格会导致语法错误
- 推荐直接使用 base64 占位图，彻底规避路径风险：
onerror="this.src='data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iI2ZmZiIvPjwvc3ZnPg=='; this.onerror=null;" - 若用相对路径，务必确认该路径在所有上下文（如子路由、iframe、file://）下都可访问
动态插入的 img 元素 onerror 绑定时机很关键
如果先 appendChild() 再绑定事件，首次加载失败已发生，onerror 根本不会执行。正确做法是：
- 创建元素后、插入 DOM 前，就设置
img.onerror = function() { this.src = '...'; this.onerror = null; }; - 避免用字符串拼接内联事件（如
'<img onerror="..." alt="HTML写onerror出现死循环怎么修改？避开死循环规范写法" >'），易 XSS 且难以维护 - 对大量动态图片，改用全局捕获更稳妥：
document.addEventListener('error', e => { if (e.target.tagName === 'IMG' && !e.target.dataset.handled) { e.target.dataset.handled = '1'; e.target.src = 'data:image/png;base64,...'; } }, true)
哪些情况 onerror 根本不触发，别白忙活
它只响应“请求发出后网络失败”，以下场景完全沉默，靠 onerror 无法兜底：
立即学习“前端免费学习笔记（深入）”；
-
src为空字符串、undefined或纯空格 —— 浏览器压根不发请求 - CORS 阻塞（比如跨域图片没加
crossorigin）—— 控制台报错，但onerror不进 - 服务器返回 200 状态码的兜底页（如某些 CDN 的“图片不存在”HTML 页面）—— 浏览器认为成功
- 图片文件头正常但数据损坏（如 JPEG 解析失败）—— 可用
img.naturalWidth === 0辅助检测，但需额外 JS
真正健壮的图片容错，从来不是只靠一个 onerror 属性。它只是三层防线里最外层的一环：网络失败靠它，格式兼容靠 <picture>，资源可用性靠 src 指向高可用地址。漏掉任何一层，降级就可能失效。
