直接写<img src="x.webp">在旧浏览器中必然空白，因Safari≤13.1、IE、旧Android WebView根本不识别image/webp MIME类型，静默丢弃请求；必须用<picture>显式声明type="image/webp"并配静态JPEG/PNG的<img>兜底。
直接写 <img src="x.webp"> 在旧浏览器里必然空白，这不是“兼容性差”，而是浏览器压根不识别 image/webp MIME 类型，连解码器都不加载——必须用 <picture> 显式声明格式优先级，并配静态 JPEG/PNG 作为强制兜底。
为什么 <img src="x.webp"> 会白屏而不是报错
因为 Safari ≤13.1、IE、旧版 Android WebView 根本不在 MIME 白名单里注册 image/webp。遇到就静默丢弃，既不请求、也不报错、更不会 fallback。你看到的“空白”，其实是资源被跳过后的默认渲染结果。
- 不是网络问题：Network 面板里根本看不到该请求
- 不是路径问题：即使 URL 正确，浏览器也不会发请求
- 不是 JS 干扰：这事发生在 HTML 解析阶段，和脚本无关
<picture> 中 <source type> 的写法必须严格匹配标准 MIME
type 属性不是“大概对就行”，错一个字符就失效。服务器返回的 Content-Type 和 HTML 里写的 type 必须完全一致。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- ✅ 正确：
type="image/webp"、type="image/avif"、type="image/jpeg"（注意是jpeg，不是jpg） - ❌ 错误：
type="webp"、type="image/jpg"、type="image/png "（末尾空格） - Chrome 可能侥幸加载错写的
type，但 Safari 会彻底跳过——不可靠
<source> 顺序 = 加载优先级，<img> 是唯一强制兜底
浏览器从上到下逐条检查 <source>，满足两个条件才停：type 被支持 + 对应资源可解码（文件存在、格式合法、网络可达）。不满足就继续往下看。
立即学习“前端免费学习笔记（深入）”；
- 把
image/avif放最前：现代 Chrome/Firefox/Edge 可用，旧 Safari 自动跳过 - 接着放
image/webp：覆盖 iOS 14+、Android 4.0+、绝大多数桌面浏览器 -
<img src="logo.jpg">不是“第三个选项”，是结构终点——漏掉整个<picture>就白屏 -
<img>的src必须是静态可直访路径，不能带查询参数（如?format=webp或?x-oss-process=...），否则旧浏览器可能返回 406 或损坏数据
容易被忽略但致命的细节
降级结构写对了，图片仍白屏？大概率卡在这几个地方：
-
<img>的src地址必须能在浏览器地址栏单独打开并显示正常图片——这是验证路径和 MIME 的最快方式 - 所有格式图片的宽高、构图、裁剪比例必须一致，否则切换时视觉跳变，用户感知为“闪白”
-
alt属性不可省：不填会导致无障碍失败，SEO 权重归零，部分读屏软件还会报错 - 服务器必须真实返回匹配的
Content-Type：Nginx 需配置types { image/webp webp; }，CDN 要开启 WebP 自动识别或手动设置响应头
