onerror事件在img加载失败时触发，用于隐藏或替换破损图，需内联绑定或js赋值，推荐用this.style.display='none'实现可靠隐藏。
img 标签加载失败时触发 onerror 事件
当 src 地址无法返回有效图片（如 404、跨域拒绝、格式错误），浏览器会在加载失败后触发 onerror 事件。这是隐藏或替换破损图的最直接切入点，且所有现代浏览器（包括 Edge、Safari、Chrome、Firefox）都支持。
注意：onerror 不会冒泡，也不能用 addEventListener 捕获（除非手动绑定），必须写在标签内或通过 img.onerror = handler 赋值。
- 仅对
src加载失败触发；srcset中某一项失败不会单独触发 - 如果图片已缓存但内容损坏（如空文件、截断的 JPEG），部分浏览器仍会触发
onerror，但行为不完全一致 - 不要在
onerror里再次设置同一个src，否则可能无限循环
用 onerror 隐藏破损图的三种可靠写法
核心思路是：失败后把图片设为不可见，同时避免留白或布局塌陷。以下写法均经实测兼容 HTML5 标准，无需额外 JS 初始化。
✅ 推荐方案（内联样式 + 隐藏）：
立即学习“前端免费学习笔记（深入）”；
@@##@@
✅ 兜底方案（降级为透明占位，保留原始尺寸）：
@@##@@
✅ CSS 驱动方案（配合 class 控制）：
@@##@@
对应 CSS：
.hidden-img { display: none; }
- 避免用
visibility: hidden—— 它仍占布局空间，可能撑开容器 - 慎用
width: 0; height: 0—— 可能导致父容器高度坍缩，影响流式布局 - 若页面大量图片，建议统一用 JS 批量绑定
onerror，而非每个标签写内联脚本
服务端 fallback 与前端容错的分工边界
HTML5 本身不提供自动 fallback 图片机制（不像 srcset 的多格式协商）。所谓“容错”，本质是前端拦截失败并干预渲染，而非改变资源请求逻辑。
-
- CDN 或 Nginx 配置 404 返回默认图（如
error_page 404 /placeholder.png）属于服务端兜底，与 HTML5 前端容错不冲突，但优先级更高 - 如果服务端已返回 placeholder，
onerror不会触发 —— 因为 HTTP 状态码是 200，只是图片内容无效 - 真正需要前端介入的场景：HTTPS 页面混入 HTTP 图片（被浏览器拦截）、动态拼接的 URL 出错、第三方图床下线等
容易被忽略的兼容细节和性能影响
看似简单的 onerror 隐藏，在真实项目中常因细节翻车。尤其要注意 Safari 对 CORS 图片的处理差异，以及 SSR 渲染时的服务端执行限制。
- Safari 15.4+ 在
crossorigin="anonymous"图片加载失败时，onerror触发但event.target.naturalWidth为 0 —— 不能依赖该值判断是否加载成功 - 服务端渲染（如 Next.js、Nuxt）中，
onerror是纯客户端行为，服务端不会执行，也不应期望它在首屏直出时生效 - 频繁触发
onerror（如列表页上百张图全部 404）会导致短时间大量 DOM 操作，可加节流或用 MutationObserver 统一收集处理 - 不要在
onerror中调用console.log或发送埋点 —— 生产环境应静默处理，避免污染日志或触发额外请求
真正健壮的破损图处理，从来不是单靠一个 onerror 属性，而是结合服务端策略、CDN 配置、前端监控和渐进式降级的组合动作。但对绝大多数静态页面来说，this.style.display='none' 这一行，已经是最轻量也最可靠的起点。
