<picture>不是为炫技而是解决资源加载本质问题，它让浏览器在请求前按media和type选择最优图源，避免小屏下载大图浪费流量。
为什么 <picture> 不是“为了更 fancy”才用
因为单靠 <img> 的 max-width: 100% 或 CSS 缩放，只改显示尺寸，不改下载体积。小屏手机照样会把 3200w 的桌面图全拉下来，浪费流量、拖慢首屏。而 <picture> 让浏览器在发起请求前就决定“该下哪张”，从源头控制资源加载。
<source> 匹配失败时为什么图片没变
常见现象：写了多个 <source>，但无论怎么缩放窗口，始终只加载最后一张或 <img> 回退图。原因不是代码写错，而是浏览器按顺序匹配——遇到第一个 media 为 true 且格式受支持的 <source> 就立刻加载，不再往下看。
- 检查
media值是否覆盖有重叠或空隙，比如(max-width: 768px)和(min-width: 769px)是安全的；但(max-width: 768px)和(min-width: 768px)在 768px 宽度时两个都可能为true，实际行为取决于浏览器解析顺序（通常取第一个） -
type="image/webp"的<source>如果放在 JPEG 后面，旧版 Safari 会跳过它直接走<img>，必须把现代格式放前面 - 没有
media也没有type的<source>会被无条件选中，导致其他条件失效
什么时候其实根本不用 <picture>
如果只是适配 DPR（比如 iPhone 14 Pro 的 3x 屏 vs 普通笔记本的 1x），或者图片构图完全一致、仅需不同分辨率，那 <img srcset="a.jpg 400w, b.jpg 800w" sizes="100vw"> 更轻量、更易维护。
-
srcset里混用w和x会失效，必须统一（推荐全用w） -
sizes必须写，否则浏览器默认按100vw算，容易选大图；而且它不支持calc()或 CSS 变量，只能是媒体查询字符串 - 生成候选图宽度建议按 1.5× 步进（如 320w → 480w → 768w → 1200w），比等比缩放更贴合真实设备逻辑像素分布
<picture> 真正不可替代的三个场景
只有这三类问题，<img> 加 CSS 或 srcset 无法干净解决，必须靠 <picture> 的声明式多源能力：
立即学习“前端免费学习笔记（深入）”；
-
艺术指导（Art Direction）：移动端要竖版特写，桌面端要横版全景，构图完全不同——
<source media="(max-width: 480px)" srcset="hero-mobile.jpg">+<source media="(min-width: 1200px)" srcset="hero-desktop.jpg"> -
格式降级：优先用
image/avif，不行再试image/webp，最后兜底image/jpeg——靠type属性分流，和media无关 -
复合条件：比如“大屏 + 支持 AVIF”用
large.avif，“大屏 + 不支持 AVIF 但支持 WebP”用large.webp，“小屏 + 任意格式”统一用small.jpg——这时<source>的排列顺序和属性组合就是关键
最容易被忽略的是：所有 <source> 都只是“建议”，最终加载哪张，由浏览器根据当前设备能力实时决策；你无法用 JS 强制切换，也不能假设它一定按你写的顺序执行——设计时得接受这个不确定性。
