浏览器不会自动 fallback，需用 onerror 事件或服务端重定向实现；onerror 最轻量但依赖 JS，服务端 fallback 更可靠。
img 的 src 加载失败时，怎么让浏览器显示备用图
浏览器不会自动尝试加载第二张图——src 404 就是 404，页面上只留一个破损图标。真要 fallback，得靠 JS 主动监听错误并换源，或者用 onerror 内联处理。
常见错误现象：<img src="a.jpg" srcset="b.jpg" /> 以为 srcset 是 fallback，其实它只是响应式候选集，和加载失败无关；<picture> 里的多个 <source> 也只管媒体查询匹配，不兜底网络错误。
-
onerror是最轻量、兼容性最好的方案，直接在标签里写：<img src="a.jpg" onerror="this.src='fallback.jpg'" /> - 注意：必须确保 fallback 图本身能加载成功，否则会无限触发
onerror（可加this.onerror=null防死循环） - 如果 fallback 图路径也动态生成，建议把逻辑抽到函数里，避免内联代码膨胀
用 <picture> + <img> 做格式降级，不是网络 fallback
<picture> 的设计目标是「根据设备能力选最优图」，不是「这张挂了换另一张」。它的执行逻辑是：按顺序检查 <source> 的 type 或 media 是否匹配，匹配成功就用那条，不匹配才落到末尾的 <img>；但一旦某条 <source> 的 srcset 地址返回 404，浏览器不会跳过它去试下一条，也不会退到 <img>。
- 典型误用：
<source type="image/webp" srcset="a.webp"><source type="image/jpeg" srcset="a.jpg">—— 如果a.webp404，页面不会自动切到a.jpg - 真正有效的格式降级，得靠服务端支持
Accept头，或前端用supports()检测后动态设置src - 想兼顾格式 + 容错，得组合用：
<picture>处理格式分支，再给内部的<img>加onerror
现代方案：CSS background-image + ::before 伪元素兜底
当图片只是装饰性内容（比如 banner 背景、icon），用 CSS 替代 <img> 可以绕过 HTML 层的加载失败问题，还能用多重背景叠加实现视觉 fallback。
立即学习“前端免费学习笔记（深入）”；
- 写法示例：
background-image: url('a.jpg'), url('fallback.jpg');—— 第一个加载失败时，浏览器会继续尝试第二个 - 注意：这仅适用于纯展示场景，无法给背景图加
alt，SEO 和无障碍支持弱于语义化<img> - 若需保留语义，可用
<img>占位 +position: absolute覆盖一层带 fallback 的背景图，但要小心 z-index 和尺寸同步
服务端重定向 or CDN 配置 fallback 更可靠，但需要权限
前端所有 JS/CSS 方案都依赖客户端执行，而有些场景（如微信内嵌页禁 JS、低配机卡顿）会导致 fallback 失效。更稳的办法是让服务器在 src 404 时直接返回一张默认图，或者由 CDN 配置 origin failover 规则。
- Nginx 示例：
location /images/ { try_files $uri /images/default.jpg; } - Cloudflare Workers 可拦截 404 响应，改写为 fallback 图的 URL
- 前提是你能控制服务器或 CDN 配置；静态托管平台（如 GitHub Pages、Vercel）通常不支持这类重写，得提前生成 fallback 占位文件
最容易被忽略的一点：所有前端 fallback 都假设“用户能执行 JS”。但某些环境（比如邮件客户端渲染、部分 RSS 阅读器、企业内网策略限制）会禁用脚本，此时 onerror 完全不触发，<picture> 也只按静态 HTML 解析。真要覆盖这些场景，唯一办法是服务端兜底或预设高容错的默认图路径。
