onerror需写在img标签内且加防重逻辑才有效，如onerror="if(!this.src.includes('fallback'))this.src='fallback.jpg'"，否则可能无限循环；空url、cors阻塞或200兜底图均不触发onerror。
img 标签的 onerror 事件怎么写才有效
直接写 onerror="this.src='fallback.jpg'" 是最常见写法，但它只在图片加载失败时触发一次，且必须确保 fallback 图片本身能加载成功，否则会无限循环报错或卡死。
实际要注意三点：
-
onerror只对<img alt="HTML怎么设置图像加载失败占位_HTML onerror事件处理教程【容错】" >标签生效，对 CSS 背景图无效 - 必须把
onerror放在<img alt="HTML怎么设置图像加载失败占位_HTML onerror事件处理教程【容错】" >标签内，不能用 JS 绑定（某些浏览器会忽略动态绑定） - 如果 fallback 图片也 404，
this.src再次赋值会再次触发onerror，得加防重逻辑
稳妥写法是：
@@##@@
为什么 onerror 有时根本不触发
不是所有“加载失败”都会进 onerror。典型不触发场景有：
立即学习“前端免费学习笔记（深入）”；
- 图片 URL 是空字符串、
undefined或纯空格 —— 浏览器可能不发请求，也就没错误事件 - 图片被 CORS 阻止（比如跨域图片没配
crossorigin），控制台报错但onerror不触发 - 图片地址是合法但返回 200 状态码的占位图（如某些 CDN 的 404 返回兜底图），这时根本不算“加载失败”
验证是否触发：打开 DevTools → Network → 刷新，看该图片请求状态码是不是 404/403/500；再看 Console 有没有 Failed to load resource。
CSS 替代方案：用 background-image + :has() 或伪元素
想统一处理所有图片容错，又不想每个 <img src="real.jpg" onerror="if (!this.src.includes('fallback')) this.src='fallback.jpg'" alt="HTML怎么设置图像加载失败占位_HTML onerror事件处理教程【容错】" > 都写 onerror？CSS 目前做不到真正等效替代，但可以绕过部分限制：
-
background-image加载失败不会触发任何 JS 事件，只能靠服务端返回兜底图或用image-set()提供多源 - CSS
:has(<img alt="HTML怎么设置图像加载失败占位_HTML onerror事件处理教程【容错】" > 或 <code>:has(<not> 能识别空 <code>src，但无法检测加载失败 - 更实用的是用伪元素覆盖：
.img-container { position: relative; }<br>.img-container::before { content: '⚠'; position: absolute; }再配合 JS 检测naturalWidth === 0来切换显示
现代方案：用 loading="lazy" 和 decoding="async" 降低失败概率
很多“加载失败”其实是资源竞争导致的超时或中断，尤其在弱网下。这两个属性能缓解：
-
loading="lazy"延迟非视口内图片加载，减少并发请求数 -
decoding="async"让解码不阻塞主线程，避免因解码卡顿被误判为失败 - 注意：两者都需搭配
onerror使用，不是替代方案，而是降低触发频率
完整示例：
@@##@@
真正难处理的是“加载成功但内容损坏”的情况，比如 JPEG 文件头正常但数据块损坏，浏览器可能渲染出花屏或黑图，onerror 完全不触发。这时候只能靠服务端校验或客户端 canvas 读取像素做二次判断 —— 但代价高，多数项目就认了。
