浏览器按<source>从上到下匹配，首个满足media和type条件的即加载，其余忽略；全不匹配才回退到<img src>。常见原因：media语法错误、srcset路径404、Content-Type不匹配、漏写<img src>。
为什么写了 <source> 却始终加载 <img src>
浏览器按 <source> 从上到下的顺序匹配，只要遇到第一个满足 media（或 type）条件的，就立刻停止并加载它的 srcset，后面的 <source> 全被忽略。如果所有都没匹配上，才 fallback 到 <img> 的 src。
常见原因包括：
-
media值写错语法，比如media="max-width: 768px"（缺括号）→ 浏览器静默跳过整条<source> - 多个
media条件重叠，例如同时写了(max-width: 768px)和(max-width: 1024px)→ 只取第一个，第二个永远不会生效 -
<source>的srcset里路径 404，或服务器返回的Content-Type和type="image/webp"不一致 → 浏览器直接丢弃该条，继续往下找 - 忘了写
<img src>，或只写了<img alt>→ 页面空白，无报错，但 Network 面板里根本没发图请求
media 和 type 同时存在时，哪个起作用
浏览器先看 media 是否匹配当前视口，再检查该 <source> 的 type 是否被支持；两者都满足，才选中它。顺序仍是关键：哪怕下一条 type 更合适，只要上一条 media 匹配了，就不会再往下走。
所以 WebP 降级链必须这样排：
<source media="(max-width: 768px)" type="image/webp" srcset="hero-sm.webp"><source media="(max-width: 768px)" type="image/jpeg" srcset="hero-sm.jpg"><img src="hero-fallback.jpg" alt="...">
不能把 JPEG 放 WebP 上面，也不能把宽屏规则写在窄屏前面——否则宽屏用户永远看不到窄屏图。
sizes 必须和 srcset 的 w 描述符配对使用
sizes 不是 CSS 属性，它是给浏览器看的“这张图在页面里大概占多宽”的提示字符串。只有当 srcset 用的是 w（如 photo-800w.jpg 800w）时，sizes 才参与计算；用 x（如 photo@2x.jpg 2x）时，sizes 可省略，但仅适用于 DPR 适配。
典型错误写法：sizes="50vw" 却配了 srcset="photo@2x.jpg 2x" → 浏览器无法换算，可能加载错尺寸。
正确搭配示例：
<source media="(max-width: 480px)" srcset="hero-320w.jpg 320w, hero-480w.jpg 480w" sizes="(max-width: 480px) 100vw">
注意：sizes 中的单位只能是 vw、px 或 em，不能写 %、calc() 或 CSS 变量。
哪些场景非用 <picture> 不可
日常宽度适配（比如小屏加载小图、大屏加载大图）用 <img srcset> + sizes 就够了，更轻量、容错更强。<picture> 只在两类硬需求下绕不开：
- 艺术方向裁剪（art direction）：移动端需要竖构图特写，桌面端需要横构图全景——单靠缩放同一张图做不到内容切换
- 格式强制降级：想让支持 AVIF/WebP 的浏览器优先加载，不支持的自动回退到 JPEG，且不想依赖 JS 检测或服务端 UA 判断
这两类问题里，<source> 的 media 或 type 是唯一能声明式控制资源选择的手段。但别忘了：<picture> 本身不压缩图片、不减少请求数、也不触发懒加载——它只是把选择权交出去，真正提速还得靠构建压缩、CDN 分发、loading="lazy" 配合。
