浏览器按顺序匹配第一个满足条件的<source>，不依赖JavaScript或智能推测，从上到下检查media或type，匹配即加载并停止；必须以合法<img>为fallback，否则静默留白。

浏览器按顺序匹配第一个满足条件的

它不靠 JavaScript 控制，也不做“智能推测”，就是从上到下逐个检查 <source> 的 media 或 type 是否为真，一旦匹配就立即加载并停止后续判断。

常见错误现象：

• 写了两个重叠断点，比如 max-width: 768px 和 min-width: 768px，结果在 768px 宽度时行为不确定
• 把宽屏规则放最后，窄屏规则放最前，导致桌面端永远只加载手机图
• media 写成 "768px" 或 "tablet"，不是合法 CSS 媒体查询，整个 <source> 被忽略

必须有 <img> 作为 fallback，且带 src 和 alt

没有它，<picture> 在不匹配任何 <source> 时渲染为空白区域——不是报错，是静默失败。

使用场景：

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

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

• 老浏览器（如 IE）完全不识别 <picture>，直接跳过所有子元素，只渲染 <img>
• 所有现代浏览器在 media 不匹配、type 不支持、或网络异常时，都会退回到 <img src="...">
• alt 不只是无障碍要求，也是 SEO 和图片加载失败时的可见文案

srcset 在 <source> 里只管“选哪张图”，不管“加载多大”

很多人混淆 art direction 和响应式缩放：<source> 的 srcset 是为不同构图准备的独立文件（如 hero-mobile.jpg、hero-desktop.jpg），不是同一张图的不同尺寸版本。

性能 / 兼容性影响：

• 如果同时想支持 Retina 屏，得写成 srcset="hero-mobile@1x.jpg 1x, hero-mobile@2x.jpg 2x"，但不能混用 w 和 x 描述符，否则整条 srcset 失效
• sizes 属性只能写在 <img> 上，不能写在 <source> 里；它的作用是告诉浏览器“这张 fallback 图大概占多宽”，防止小屏误加载大图
• 所有 srcset 和 src 路径必须真实存在，404 不会报错，只会静默降级——调试得靠 Network 面板清缓存后看实际请求了哪个 URL

type 属性用于格式优先级，不是可选项

当你要用 image/avif 或 image/webp 时，type 是关键开关。浏览器只在支持该 MIME 类型时才考虑对应 <source>，否则跳过。

实操建议：

• 把现代格式 <source> 放最前面，旧格式（如 JPEG）放后面，实现“WebP/AVIF 优先，JPEG 保底”
• 不要只写 type="image/webp" 却省略 media，否则它会在所有设备上参与匹配，可能挤掉更合适的尺寸版本
• 同一张图的 WebP 和 JPEG 版本，文件名别只差个后缀（如 hero.jpg vs hero.webp），容易在 CDN 缓存或路径处理时出错；建议显式命名，如 hero-webp.webp 和 hero-jpg.jpg

真正起作用的是结构和顺序，不是属性堆砌。最容易被跳过的硬性要求：最后一个子元素必须是 <img>、所有路径必须可访问、media 必须是合法媒体查询——缺一不可，否则页面就留白。