<picture> 本身不实现响应式，而是提供资源选择机制；必须嵌套带 src 的 <img> 作为兜底，<source> 按顺序匹配且需同时满足 media 和 type，sizes 必须与 srcset 的 w 描述符配合使用，AVIF/WebP fallback 应按格式支持度降序排列并确保 <img src> 为通用格式。
<picture> 标签不是“让图片自动变响应式”的开关，它本身不改变图片尺寸或加载行为，而是提供一套声明式的资源选择机制——浏览器根据 media、srcset、sizes 和文件格式支持，自主决定加载哪张图。
为什么 <picture> 不能替代 <img> 的 src
很多初学者写完 <picture> 就忘了内部必须嵌套一个 <img> 元素，且该 <img> 必须带 src 或 srcset。否则：
- 所有现代浏览器都会忽略整个
<picture>，降级渲染为空白（无报错） - 屏幕阅读器无法获取替代文本，因为
alt只在<img>上生效 -
<source>标签只是提示，不承载内容；最终渲染和可访问性全靠那个<img>
正确结构底线：<picture><source>...</source><img src="fallback.jpg" alt="描述"></picture>。这个 src 是兜底 URL，必须存在且可访问。
<source> 的 media 和 type 到底谁优先？
浏览器按 <source> 出现顺序依次匹配，遇到第一个满足条件的就停止，加载其 srcset 指定的资源。这意味着：
-
media（如(min-width: 768px)）只在视口宽度满足时才“启用”该<source> -
type（如image/webp）只在浏览器支持该 MIME 类型时才考虑该<source> - 两者是“与”关系：必须同时满足
media成立 且type可用，才会选中 - 如果第一个
<source>的type不被支持（比如只写了webp，但用户用 Safari 13 前），即使media匹配，也会跳过
常见错误：把 webp 放最前却不提供 fallback jpg <source>，导致部分浏览器白屏。
sizes 属性为什么必须和 srcset 配合用？
sizes 不是给图片设宽高，而是告诉浏览器：“在不同断点下，这张图将占据视口宽度的多少”。没有它，srcset 中的 w 描述符（如 400w）就失去参照系，浏览器只能按 1x 像素密度粗略估算，可能选错资源。
- 典型写法：
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw" - 对应
srcset必须是宽度描述符（400w, 800w, 1200w），不能混用x（如1x, 2x） - 如果用了
x描述符，sizes可省略，但会丢失对多分辨率 + 多布局的精细控制 - 注意单位：
vw是视口宽百分比，em/px在sizes中无效
漏掉 sizes 或写错断点逻辑，是响应式图片加载偏大/偏小的最隐蔽原因。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
WebP / AVIF 图片 fallback 怎么写才真正可靠？
仅靠 <source type="image/avif"> + <source type="image/webp"> + <img> 不够。真实场景要防三类失效：
- 旧浏览器（如 IE11、Android 4.4 WebView）既不识别
<picture>，也不支持type属性 → 它们直接忽略所有<source>，只加载<img src>，所以<img>的src必须是jpg或png - 较新但不支持 AVIF 的浏览器（如 Chrome 91–100）会跳过
avif<source>，继续匹配下一个（比如webp），没问题 - 支持 AVIF 但禁用 JS 的环境（少见）仍能走原生
<picture>流程，无需额外处理
安全写法顺序：AVIF → WebP → JPG/PNG（通过 <img> 的 src）。不要把 jpg 放 <source> 里——它没意义，因为所有浏览器都支持 JPG，没必要用 <source> 提示。
真正难的是测试：得开多个设备/模拟器，关掉开发者工具的“网络节流”干扰，用 chrome://net-internals/#events 看实际加载了哪个 URL。不然你以为用了 AVIF，其实一直 fallback 到 JPG。
