<picture>比单纯用<img src="xxx.webp">更可靠，因为浏览器不支持WebP时后者直接空白，而<picture>通过<source type="image/webp">+<img>兜底确保基本可用；type必须严格匹配标准MIME类型且区分大小写，浏览器按顺序选取首个匹配源。
为什么 <picture> 比单纯用 src 更可靠
因为浏览器不支持 WebP 时，<img src="xxx.webp"> 会直接显示空白或报错（比如 Chrome 早期版本、Safari 13.1 之前），而 <picture> 提供了明确的回退路径。它不是“增强兼容性”，而是“保证基本可用”——只要有一个 <source> 被支持，图片就能加载。
<source> 的 type 属性必须写对
常见错误是写成 type="image/webp" 却漏掉引号、大小写错误，或误用 media 替代 type。浏览器只认标准 MIME 类型，且区分大小写；不匹配就跳过该 <source>，继续往下找。
正确写法示例：
<picture> <source srcset="hero.webp" type="image/webp"> <source srcset="hero.avif" type="image/avif"> <img src="hero.jpg" alt="Hero"> </picture>
-
type值必须是字符串字面量，不能是变量或表达式 - 顺序很重要：浏览器从上到下检查
<source>，第一个匹配的就用，后面的全忽略 - 没有
type的<source>会被当作普通srcset处理，可能触发意外加载
WebP + srcset 配合 sizes 才真正生效
只写 srcset="small.webp 480w, medium.webp 768w" 不够——浏览器不知道在什么视口宽度下用哪张。必须配 sizes，否则默认按 100vw 计算，容易选错分辨率，甚至加载超大图。
立即学习“前端免费学习笔记（深入）”；
典型搭配：
<picture>
<source
srcset="hero-480.webp 480w,
hero-768.webp 768w,
hero-1200.webp 1200w"
sizes="(max-width: 480px) 100vw, (max-width: 768px) 100vw, 1200px"
type="image/webp">
<img src="hero-1200.jpg" alt="Hero">
</picture>
-
sizes是 CSS 长度描述，不是像素值本身，但必须和实际布局一致 - 所有
<source>的sizes应保持一致，否则不同源可能按不同逻辑选图 - 如果只有一张 WebP，
srcset可省略，直接用src，但失去响应式能力
Safari 14+ 支持 WebP，但某些旧 iOS 版本仍需验证
虽然 Safari 14（2020 年底）开始支持 WebP，但部分 iOS 14.0–14.2 用户报告有解码异常（如绿屏、卡顿）。这不是 <picture> 写法问题，而是系统级解码器缺陷。稳妥做法是：对 iOS 用户额外加一层 UA 判断，或把 JPEG 回退放在更靠前的位置。
- 不要依赖
navigator.userAgent做运行时切换——<picture>是静态解析的，JS 插入无效 - 可服务端根据
User-Agentheader 输出不同 HTML，但成本高 - 最简方案：把高质量 JPEG 放在最后一个
<source>之后的<img>中，确保它总能兜底
WebP 的压缩优势明显，但它的“兼容性开关”不在文件本身，而在你是否给浏览器留了清晰、无歧义的加载指令——<picture> 不是锦上添花，是 WebP 落地的必要容器。
