<picture> 标签本身不加载图片，仅作为容器；真正触发加载的是内部 <source> 规则匹配后对应的资源及必需的 <img> 元素——无 <img> 则无渲染、无请求。
<picture> 标签本身不加载图片，它只是个容器；真正决定加载哪张图的是内部的 <source> 规则和最终的 <img> 元素 —— 没有 <img>，<picture> 就不会渲染任何内容，也不会触发任何图片请求。
为什么加了 <source> 但始终加载默认 <img>？
浏览器按 <source> 顺序逐条匹配，遇到第一条满足条件的就停止，跳过后续所有 <source> 和 <img> 的 src 解析（但 <img> 仍必须存在，否则无图）。
-
media属性只支持媒体查询语法（如(max-width: 768px)），不支持 JS 表达式或自定义变量 -
type必须与实际响应的 MIME 类型严格一致（例如image/webp返回image/jpeg会静默回退到<img>） - Chrome 120+ 开始对
media中的min-resolution支持更严格，用dppx替代dpi更可靠（(min-resolution: 2dppx)） - 不要在
<source>上写srcset却漏掉media或type—— 缺失关键属性时该<source>直接被忽略
<source> 的 srcset + sizes 和 <img> 的 srcset + sizes 是两套独立逻辑
每个 <source> 自己的 srcset/sizes 只服务于它自身匹配成功后的资源选择；而 <img> 的 srcset/sizes 只在所有 <source> 都不匹配时才生效。
-
<source sizes="(max-width: 480px) 100vw, 50vw">中的sizes值仅影响该<source>内部srcset的计算，不影响其他<source>或<img> - 如果某个
<source>匹配成功但它的srcset里没有适配当前 DPR 的尺寸（比如只有1x图但设备是2x），浏览器仍会加载其中最接近的，不会跨<source>查找 -
<img>的src是 fallback，但srcset+sizes是 fallback 场景下的响应式增强 —— 两者可共存
WebP/AVIF 回退失效的三个典型原因
不是所有“不支持 WebP”的浏览器都会自动走 <img>；部分旧版 Safari、Firefox 在 type="image/webp" 不匹配时，可能直接空白，而不是降级。
立即学习“前端免费学习笔记（深入）”；
- 检查网络面板：如果看到
net::ERR_ABORTED或状态码 406，说明服务器拒绝了 WebP 请求（常见于 Nginx 未配置Accept头转发） - 避免只靠
type判断：某些 Android WebView 对image/avif声称支持，但实际解码失败，建议搭配media="(min-width: 0px)"强制兜底 - 最稳的回退结构是把兼容性最强的格式（如 JPEG）放在最后一个
<source>，再紧跟<img src="fallback.jpg">—— 这样即使所有<source>都跳过，也有确定出口
真正难调的不是语法，而是不同设备对 media 查询的解析差异、CDN 对 Accept 头的透传策略、以及图片服务返回的 Content-Type 是否和 <source type> 完全一致 —— 这些地方一错，就变成“写了等于没写”。
