最稳妥的onerror写法是先执行this.onerror=null再替换图片，或使用data URL降级；CSS background-image多重声明可静默fallback；<picture>配合onerror实现双层兜底。
img 标签的 onerror 事件怎么写才不重复触发
直接在 <img> 上写 onerror="this.src='fallback.jpg'" 是常见做法，但容易陷入无限循环：如果 fallback.jpg 也加载失败，会再次触发 onerror，反复尝试，甚至导致页面卡顿或报错堆叠。
关键是要确保降级路径只执行一次。最稳妥的做法是把备用图设为内联 data URL（比如一个极小的 SVG 占位符），或者用 JS 控制开关：
- 用
this.onerror = null在回调里先清空事件处理器，再换图 - 避免把
onerror写成内联字符串，改用addEventListener更易管理 - data URL 降级（如
data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='1' height='1'%3E%3C/svg%3E）完全规避网络请求失败风险
用 CSS background-image 实现更可控的降级
当图片语义性不强（比如装饰性 banner、头像背景），用 background-image 配合 @supports (background-image: element()) 或多重 background-image 声明，能自然 fallback 到纯色或 base64 图片。
CSS 的优势在于浏览器会静默处理加载失败，不会抛错误、不触发 JS 事件，也不影响 DOM 结构。示例：
立即学习“前端免费学习笔记（深入）”；
.avatar {
background-image: url('photo.jpg'), url('placeholder.svg');
background-image: url('photo.jpg'), linear-gradient(#eee, #ddd);
}
注意：多个 url() 用逗号分隔时，浏览器按顺序尝试，第一个能加载就停；后面的仅作 fallback，不额外请求。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
现代方案：使用 loading="lazy" + 无 JS 的 fallback 图片组
HTML5 原生支持 <picture>，配合 <source> 和 <img> 的 srcset，可让浏览器根据格式支持、尺寸、网络条件自动选图——其中任意一个失败，会继续尝试下一个，无需 JS 干预。
但要注意：只有 <source> 的 type 或媒体查询匹配时才会尝试加载；真正的“失败降级”仍依赖 <img> 的 onerror。所以推荐组合写法：
- 优先用
<picture>处理格式兼容（如 WebP → JPEG） - 再给内部
<img>加一层onerror处理最终兜底 - 避免在
<source>上写onerror—— 它不支持该事件
服务端返回 404 时，前端如何识别并响应
浏览器对图片加载失败不会抛出可捕获的 JS 错误（fetch 会，但 <img> 不会），所以不能靠 window.addEventListener('error') 精准定位哪张图挂了。
唯一可靠方式仍是 onerror 回调。但如果你用的是 CDN 或代理服务，可以利用响应头做辅助判断：
- 某些 CDN（如 Cloudflare）会在图片 404 时返回带
X-Content-Type-Options: nosniff的响应，但前端无法读取 - 真正可用的是：后端统一返回一个带特定 query 的 fallback 图，例如
https://i.example.com/missing?src=xxx，然后在onerror里检查this.src.includes('missing')防止二次替换 - 不要依赖
event.target.naturalWidth === 0判定失败——Safari 下可能不准，且需等待图片解析完成
最麻烦的地方往往不在写法，而在于降级逻辑和原始图片加载是否共享缓存策略、是否受 CSP 限制、以及 SSR 渲染时服务端根本不会触发 onerror —— 这些边界情况，容易被本地开发忽略。
