<picture>是条件分发器，按顺序匹配首个合法<source>（media/type需正确），全不匹配则fallback至<img src>；sizes必须写在<img>上且带单位，srcset中w与x描述符不可混用。
<picture> 标签本身不渲染、不加载、不执行，它只是个“条件分发器”——浏览器按顺序读取子元素，遇到第一个合法匹配的 <source> 就停，加载它的资源；全不匹配就用 <img> 的 src。写错一个括号或 MIME 类型，整个逻辑就静默失效。
浏览器怎么选 source：顺序 + 第一个匹配，不是最优解
浏览器不会比较所有 <source> 然后挑“最合适的”，它从上到下逐行解析，只要当前 <source> 的 media 为真、或 type 受支持且 srcset 有可用候选，就立刻加载并终止后续检查。
- 把宽屏规则（如
(min-width: 1440px)）放在最上面，窄屏兜底（如(max-width: 480px)）放最后 - 写成
media="max-width: 768px"❌（缺括号）→ 整个<source>被忽略 - 断点重叠（如
(max-width: 768px)和(min-width: 768px)）→ 768px 宽度行为未定义，推荐用开区间：max-width: 767px→min-width: 768px→min-width: 1201px
type 属性必须和服务器 Content-Type 完全一致
type 不是“建议格式”，而是硬性准入门槛：浏览器看到 type="image/webp"，就会检查响应头 Content-Type: image/webp。任何偏差都会导致该 <source> 被跳过。
- 拼写错误：写成
image/jpg❌（正确是image/jpeg） - 大小写/空格：
IMAGE/WEBP或image/webp（末尾空格）→ Chrome 标记为blocked:mime-type - 服务器未配置：Nginx/Apache 没配 WebP MIME 类型，返回
text/plain或application/octet-stream→ 直接失效 - Network 面板里看到请求状态是
blocked:mime-type，基本就是这个原因
sizes 必须写在 <img> 上，且单位不能少
sizes 不影响 <source> 匹配，只影响该 <source> 或 <img> 内部 srcset 中 w 描述符的计算。它必须出现在 <img> 标签上，且每个媒体条件后的宽度值必须带单位（vw、px 等）。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 写成
sizes="(max-width: 768px) 100%, 50vw"❌（100%不是合法 sizes 值） - 漏掉单位：
sizes="(max-width: 768px) 100, 50vw"❌（100无单位） - 没写
sizes却用了w描述符 → 浏览器默认按100vw计算，可能拉下远超需要的大图 - 你的 CSS 实际让图片占 33vw？那就得写
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
srcset 里 w 和 x 描述符不能混用
同一个 srcset 值里，要么全用 w（视口宽度适配），要么全用 x（DPR 适配）。混用会导致整条 srcset 被浏览器忽略，回退到 <img> 的 src。
- 合法：
hero@1x.jpg 1x, hero@2x.jpg 2x - 合法：
hero-400w.jpg 400w, hero-800w.jpg 800w - 非法：
hero-400w.jpg 400w, hero@2x.jpg 2x→ Safari/Chrome 表现不一，多数直接跳过 -
x描述符下，建议按 DPR 升序排列：1x在前、3x在后，浏览器从左到右匹配，找到第一个 ≥ 当前window.devicePixelRatio的就停
最容易被忽略的其实是三件事：所有 <source> 的 media 必须是完整合法媒体查询；<img> 必须存在且带 src 和 alt；每个 srcset 路径必须真实可访问——404 不报错，只静默 fallback，得靠 Network 面板清缓存后看实际发了哪些请求才能确认问题在哪。
