必须用<picture>+<source type="image/webp">实现条件加载，且<img>为不可省略的兜底；直接<img src="x.webp">在Safari≤13.1、IE等不支持WebP的浏览器中会白屏，因HTML无自动格式fallback机制。
能，但必须严格按顺序写 <source> 并配一个可访问的 <img src> 兜底，否则 Safari 13.1 前、IE、旧 Android WebView 会白屏。
为什么单用 <img src="x.webp"> 不行
浏览器不会“自动识别格式然后换一个”。<img src="x.webp"> 在不支持 WebP 的环境里（比如 Safari ≤13.1、IE、部分 Android WebView）直接加载失败，渲染为空白，控制台通常无报错，只看到 Network 面板里 status 是 404 或 406（如果后端做了 MIME 检查）。
这不是 bug，是规范行为：HTML 不定义格式 fallback 机制，<img> 只负责加载一个 URL。
常见错误场景：
立即学习“前端免费学习笔记（深入）”；
- 把 WebP 放在
<picture>最前面，但没写任何<source type="image/jpeg">或兜底<img src="x.jpg"> - 兜底
<img src>指向带查询参数的地址（如"x.jpg?format=webp"），旧 WebView 加载失败 - 误以为
srcset或sizes能替代<img src>，结果整个<picture>被忽略，页面空白
<picture> 里 <source> 的顺序和 type 必须降序排列
浏览器从上到下逐个检查 <source>，遇到第一个同时满足 media（视口条件）和 type（格式支持）的就停止，加载它指定的资源。所以顺序 = 优先级。
推荐写法（WebP 优先，JPEG 兜底）：
<picture> <source srcset="hero.webp" type="image/webp"> <source srcset="hero.avif" type="image/avif"> <img src="hero.jpg" alt="描述"> </picture>
注意：
- AVIF 放 WebP 后面——虽然压缩率更高，但 Safari 15.4+、Chrome 93+ 才稳定支持，放前面会导致大量用户 fallback 到 JPEG
- 所有
<source>都不加media时，等价于“只要支持该格式就用”，适合全屏大图 - 不要给
<source>加alt——它不参与可访问性，alt必须且只能写在<img>上
兜底 <img src> 必须是真实可访问的 JPEG/PNG
这个 <img> 不是“摆设”，它是 IE 和旧 WebView 唯一能识别并渲染的部分。一旦它失效，整个图片区域就空了。
关键要求：
-
src必须是静态路径，不能含动态参数（如"x.jpg?x-oss-process=image/format,webp"） - 文件必须真实存在，HTTP 状态码为 200，且响应头
Content-Type是image/jpeg或image/png - 尺寸、构图需与 WebP/AVIF 版本完全一致，否则视口切换或 fallback 时会出现跳变
- 如需首屏高优加载，
fetchpriority="high"必须加在<img>上，加在<source>上无效
旧 Android WebView 白屏问题怎么绕过
Android 4.4–6.x 的 WebView 对 <picture> 支持极差：部分版本解析失败直接空白，不 fallback 到内部 <img>。
稳妥方案只有两个：
- 服务端 UA 检测，对已知缺陷 WebView 直接输出
<img src="x.jpg">，跳过<picture> - 前端 JS 特性检测 + 动态插入：
document.createElement('img')替换容器内容，但会牺牲 SEO 和初始 HTML 可访问性
最容易被忽略的一点：所有格式图片的宽高比、裁剪方式、焦点位置必须严格一致。哪怕只是 WebP 多压了 2% 导致文字边缘模糊，用户从 JPEG 切到 WebP 时也会觉得“图动了一下”。
