html图片降级需结构、type值、服务器content-type、兜底四者协同，缺一即静默白屏；type必须严格匹配标准mime（如image/webp），服务器须配置正确响应头，须为静态可访问jpeg/png路径。
直接说结论：HTML图片降级不是“写个备用地址”就完事，而是由 <picture></picture> 结构、type 值、服务器响应头、<img> 兜底四者共同决定的链路。漏掉任一环，降级就静默失败——页面白屏或只显示 alt 文本。
为什么 写对 MIME 类型才管用
浏览器不看文件后缀，只比对 type 属性和服务器返回的 Content-Type 响应头是否严格一致。写错就等于主动跳过该 <source></source>。
- ✅ 正确：
type="image/webp"、type="image/avif"、type="image/jpeg" - ❌ 错误：
type="webp"（缺image/）、type="image/jpg"（JPG 标准 MIME 是image/jpeg）、type="image.webp"（用点号非斜杠） - 服务器没配好也会失效：Nginx 需加
types { image/webp webp; }，否则返回text/plain，Safari 会静默忽略
为什么 ![]()
必须存在且 src 不能是动态地址
<picture></picture> 本身不渲染也不请求资源，最终触发加载的是匹配成功的 <source></source> 或内部的 <img>。IE 和旧 Android WebView 完全不解析 <picture></picture>，只会读取并加载 <img src>。
-
<img>的src必须指向一个真实可访问的 JPEG/PNG（如/images/logo.jpg），不能是带查询参数的动态 URL（如logo.jpg?format=webp） - 不要把
<img>的src指向 WebP/AVIF：旧浏览器无法解码，结果就是空白 - 如果所有
<source></source>都因 404 或跨域失败，浏览器仍会尝试加载<img>；若它也 404，就只剩alt文本
为什么 loading="lazy" 单独用会白屏
loading="lazy" 是浏览器原生特性，不支持时它直接被忽略——但此时若 src 是空值、占位图或无效路径，图片就不会加载，用户看到的就是白块。
- 必须同时维护两套地址：
src指向可用占位图（如 1px GIF 或 LQIP），data-src存真实高清图地址 - 关键图片（如首屏主图、商品图）建议跳过懒加载，直接写死
src，不设data-src - JS 加载失败时，
data-src就不存在；所以初始化逻辑要内联，且检测到IntersectionObserver不可用时，立刻批量赋值src = this.dataset.src
为什么 onerror 处理要慎用
<img onerror="this.src='fallback.jpg'"> 看似简单，但在实际链路中容易触发多次、错失时机或掩盖真正问题。
- 仅适用于静态单图场景；
srcset或sizes复杂时，onerror无法区分是哪个资源失败 - 如果 fallback 图也 404，会再次触发
onerror，形成无限循环（部分浏览器会限制次数，但不可依赖） - 更稳妥的做法是：服务端确保
<img>的src本身高可用（比如指向 CDN 托管的默认占位图），而非靠 JS 或事件兜底
最容易被忽略的是格式一致性：所有 <source></source> 和 <img> 对应的图片，必须尺寸相同、构图一致。否则降级切换时，用户会看到明显跳变——这不是技术问题，是视觉体验断层。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
