降级失效主因是缺失或错误配置强制兜底的 标签，且其 src 必须为静态可访问路径；type 属性须与服务器 Content-Type 完全一致，顺序应为 AVIF→WebP→JPEG，宽高需统一以防跳变。
直接写 <img src="logo.webp" alt="HTML图片降级常见错误怎么解决" > 在 Safari 13.1 以下、IE 或旧版 Android WebView 中会留白，不是“加载慢”，是浏览器压根不识别 image/webp MIME 类型，连请求都不会发——降级必须靠 <picture></picture> 显式声明 + 静态兜底。
为什么 里写了 还是空白
最常见原因是漏掉强制兜底的 <img alt="HTML图片降级常见错误怎么解决" > 标签，或它的 src 指向了不可直访的地址。
-
<img alt="HTML图片降级常见错误怎么解决" >不是可选项：没有它，整个<picture></picture>结构就不触发加载，浏览器不会自动 fallback 到第一个<source></source> -
<img src alt="HTML图片降级常见错误怎么解决" >必须是静态、通用、无需协商的路径：不能带?format=webp、?x-oss-process=等动态参数，否则旧浏览器可能返回 406 或损坏数据 - 在浏览器地址栏单独打开
<img src alt="HTML图片降级常见错误怎么解决" >的 URL，必须能正常显示图片——这是验证兜底是否有效的最快方式
type 属性写错导致所有 source 都被跳过
type 值不是“大概对就行”，而是必须和服务器返回的 Content-Type 完全一致，否则 Safari 会静默忽略整条 <source></source>。
- ✅ 正确：
type="image/webp"、type="image/avif"、type="image/jpeg"（注意是jpeg，不是jpg） - ❌ 错误：
type="webp"、type="image/jpg"、type="image.webp" - 服务器返回
Content-Type: image/webp，但 HTML 写成type="webp"→ Safari 跳过，Chrome 可能侥幸加载，但不可靠
AVIF/WebP 顺序和 fallback 失效的连锁反应
浏览器按 <source></source> 从上到下匹配，只取第一个“类型支持 + 资源可解码”的，后续全部跳过。顺序错了，现代格式就用不上；顺序对了，但 JPEG 没放对位置，旧设备照样空白。
立即学习“前端免费学习笔记（深入）”；
- 推荐顺序：
<source srcset="logo.avif" type="image/avif"></source>→<source srcset="logo.webp" type="image/webp"></source>→<img src="logo.jpg" alt="Logo"> - 不要把 JPEG 放进第三个
<source></source>：它只是格式 fallback，不是响应式 fallback；只有<img src alt="HTML图片降级常见错误怎么解决" >才是最终强制兜底 - 所有格式图片的宽高、裁剪比例必须一致：否则切换时视觉跳变，用户感知为“闪动”或“错位”
断网或 JS 失败时图片彻底消失的隐藏陷阱
很多人以为 <picture></picture> 是纯 HTML 行为，其实不少项目会混用 JS 动态生成 srcset 或懒加载逻辑——一旦 JS 加载失败或断网，<img alt="HTML图片降级常见错误怎么解决" > 的 src 若是空值或占位图，页面就只剩空白。
-
<img src alt="HTML图片降级常见错误怎么解决" >必须在 HTML 源码中静态存在，且指向真实可用资源（如 1px GIF、LQIP 图或 SSR 渲染出的小图） - 避免用
display: none隐藏图片容器：Safari 和多数 Android WebView 会直接跳过该元素，即使后来 show 出来也不会重新触发加载 - 如果用了懒加载，
<img alt="HTML图片降级常见错误怎么解决" >的src绝不能为空，也不能依赖 JS 补充——断网时 JS 不执行，src就永远无效
真正容易被忽略的是：降级不是“写完 <picture></picture> 就结束”，而是要验证每一条链路——type 值、服务器 Content-Type、<img src alt="HTML图片降级常见错误怎么解决" > 的可访问性、网络异常下的 DOM 状态。任何一个环节断开，用户看到的就是一片空白，而不是“稍等一下”。
