media属性只在<source>中生效，浏览器线性扫描、遇真即停；顺序须从宽到窄，否则小屏规则拦截全部；缺括号、单位、断点重叠或写在<picture>上均导致静默失效。

media 属性只在 里生效，顺序决定匹配结果

浏览器对 media 的处理是线性、短路的：从上到下扫描每个 <source>，遇到第一个满足条件的就立即停止，后面所有 <source> 和 <img> 的 srcset 都不参与本次选择。

常见错误包括：

• media 写在 <picture> 标签上（如 <picture media="(max-width:768px)">）→ 完全被忽略
• 断点重叠，比如同时存在 (min-width: 768px) 和 (max-width: 768px) → 768px 视口行为不可控，Chrome 和 Safari 可能给出不同结果
• 单位缺失：768 是非法值，必须写成 768px
• 小屏规则放最前（如 media="(max-width: 480px)" 在第一行）→ 所有设备都命中，宽屏图永远不加载

srcset 中的 w 和 x 描述符不能混用，且生效位置完全不同

srcset 的解析逻辑严格区分上下文：<source> 里的 srcset 只响应 media 匹配后的宽度级选择；<img> 的 srcset 才负责 DPR（设备像素比）适配。

关键限制：

立即学习“前端免费学习笔记（深入）”；

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• <source> 的 srcset 中写 photo@2x.jpg 2x → 浏览器直接忽略 2x，只按文件路径加载
• 同一 srcset 值中同时出现 400w 和 2x → 整个属性值被判定为无效，回退到 <img> 的 src
• <img> 的 srcset 若含 x 描述符，则 sizes 会禁用 DPR 匹配逻辑，此时必须确保所有 DPR 场景都被显式覆盖

type 属性必须与服务器返回的 Content-Type 完全一致

type 不是“建议格式”，而是硬性 MIME 类型校验。浏览器先检查 Accept 请求头是否包含该类型，再验证响应头 Content-Type 是否精确匹配——任一环节失败，该 <source> 就被跳过。

典型失效场景：

• 声明 type="image/webp"，但 Nginx 未透传 Accept 头 → 服务端返回 JPEG，Content-Type: image/jpeg → 不匹配，静默跳过
• Android WebView 声称支持 image/avif，但实际返回 Content-Type: image/webp → 匹配失败，不降级，可能空白
• 用 type="image/jpg"（错误 MIME）代替 image/jpeg → 所有浏览器均不识别

sizes 只能写在 上，且必须和 CSS 渲染尺寸对齐

sizes 的作用不是控制加载，而是告诉浏览器“这张图在布局中占多宽”，以便配合 w 描述符做宽度匹配。它只在 <img> 上生效，<source> 中的 sizes 被完全忽略。

错配后果严重：

• CSS 设置 width: 300px，但 sizes 写成 "100vw" → 浏览器预估宽度远大于实际，可能加载 2000w 图却只渲染 300px，浪费带宽
• 响应式布局中，sizes 没随断点更新（如移动端应为 "100vw"，桌面端应为 "33vw"），导致跨断点时选图失准
• <img> 缺 sizes 却用了 w 描述符 → 浏览器无法计算视口占比，回退到 src

真正难调的从来不是语法拼写，而是 media 查询在不同内核中的解析偏差、CDN 对 Accept 头的截断策略、以及图片服务返回的 Content-Type 是否和 type 声明一字不差——这些地方出问题，<picture> 就会安静地退回到 <img src>，连错误提示都不会给。