onerror死循环表现为页面卡顿、内存飙升、DevTools崩溃或标签页无响应；根本原因是fallback图持续404触发重试，需用Network面板查连续404或performance.memory验内存暴涨。
onerror死循环怎么一眼看出来
页面卡顿、内存占用飙升、DevTools 崩溃或标签页无响应，十有八九是 onerror 死循环。不是代码“没生效”，而是备用图本身也 404，触发第二次 onerror，再换图、再失败……浏览器根本来不及渲染，只在后台疯狂重试。
最直接验证方式：打开 Network 面板，过滤 Img，观察是否连续出现同一张 fallback 图的 404 请求；或者在控制台执行 performance.memory，看 usedJSHeapSize 是否在几秒内暴涨数倍。
为什么this.onerror=null还卡死
常见错误写法：onerror="this.src='fallback.png'; this.onerror=null" 看似正确，但 fallback 图路径不可达（比如相对路径拼错、CDN 下线、权限不足），this.onerror=null 执行了，可新请求又失败，而浏览器对重复 404 的 img 会静默阻止后续 onerror 触发——此时你既看不到错误，也收不到回调，只剩白屏或卡顿。
- 必须用绝对路径或 base64：
onerror="this.src='data:image/svg+xml;base64,PHN2Zy...'; this.onerror=null" - 不能依赖
this.onerror=null单一防线，要加兜底判断：onerror="if (!this.src.includes('fallback')) { this.src = '/fallback.svg'; this.onerror = null; }" - 动态插入的
<img alt="HTML调试onerror死循环怎么操作？定位死循环排错指南" >必须在appendChild()前绑定onerror，否则首次错误已发生，事件监听器根本没机会注册
如何用全局 error 事件安全捕获并终止
静态 HTML 里写内联 onerror 容易漏掉动态图或拼写错误；全局监听更可控，但必须用捕获阶段 + 数据标记防重复。
立即学习“前端免费学习笔记（深入）”；
正确写法（放在 内联脚本中）：
document.addEventListener('error', e => {
if (e.target instanceof HTMLImageElement && !e.target.dataset.handled) {
e.target.dataset.handled = 'true';
e.target.src = 'data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iI2ZmZiIvPjwvc3ZnPg==';
}
}, true);
true 是关键：确保在捕获阶段命中，覆盖所有后续插入的 <img alt="HTML调试onerror死循环怎么操作？定位死循环排错指南" >；dataset.handled 防止同一张图被多次替换；base64 SVG 彻底规避路径风险。
哪些情况onerror压根不会触发
死循环只是表象，真正麻烦的是 onerror 完全不触发却显示异常——这时你查半天代码，其实问题根本不在 JS。
-
src为空字符串、undefined或纯空格 → 浏览器根本不发请求，无事件 - 跨域图片未加
crossorigin属性 → 控制台报 CORS 错误，但onerror静默忽略 - 服务器返回 200 状态码的“兜底图”（如 CDN 的 404 占位页）→ 浏览器视为成功加载，哪怕内容是文字“Image Not Found”
- JPEG 文件头正常但数据块损坏 →
img.naturalWidth === 0可检测，但需额外轮询或load后校验
这些场景下，onerror 不是写错了，而是天生就不该指望它——得靠 IntersectionObserver 占位、服务端统一响应、或 img 加 width/height 配合 alt 文本兜底。
