解码失败与404不同：图片加载成功但naturalWidth/naturalHeight为0，显示空白或黑块；需在onload/onerror后主动检测并用base64兜底。
图片解码失败和404不是一回事
浏览器遇到损坏的 JPEG、截断的 PNG 或 WebP 文件头错误时，naturalWidth 会是 0，但控制台不报错、onerror 也不触发——它“加载成功”了，只是解码失败。这种情况下用户看到的是空白或黑块，比 404 更隐蔽。
用 naturalWidth === 0 检测解码失败
不能只靠 onerror，必须补充 JS 主动检测。关键点：
-
naturalWidth和naturalHeight都为0才能确认解码失败（单个为 0 可能是 SVG 或未加载完） - 检测时机很重要：必须等图片进入 DOM 且
complete为true后再读取，否则值不可靠 - 推荐在
img.onload和img.onerror之后统一检查，避免重复逻辑
img.onload = img.onerror = function() {
if (this.naturalWidth === 0 || this.naturalHeight === 0) {
this.src = 'data:image/png;base64,iVBORw0KGgo...';
this.dataset.loaded = 'fallback';
}
};
兜底图必须是内联 base64 或绝对路径
解码失败常发生在弱网、CDN 传输中断或构建压缩出错时，此时任何外部请求都可能再次失败。
- 避免用相对路径 fallback，比如
src="fallback.jpg"—— 当前页面路由变化后路径就失效 - 禁用带查询参数的 URL：
src="logo.jpg?v=2"在旧 WebView 中可能被截断或拒绝 - 最稳妥是
data:image/png;base64,...，1px 占位图仅 60 字节左右，零网络依赖
picture 元素里也要防解码失败
<picture></picture> 能解决格式兼容性问题，但无法绕过单个文件解码失败。降级链要贯穿到底：
立即学习“前端免费学习笔记（深入）”；
-
<source type="image/webp"></source>加载的 WebP 若损坏，浏览器不会自动跳到下一条<source></source>，更不会 fallback 到<img alt="如何在HTML中处理图片解码失败降级" > - 必须对最终渲染的
<img alt="如何在HTML中处理图片解码失败降级" >元素做naturalWidth检查，而不是只检查<source></source> - 如果用 JS 动态切换
<picture></picture>的srcset，每次替换后都要重新绑定检测逻辑
