标签仅声明备选资源，浏览器按dom顺序逐个尝试，首个type匹配且能解码的即被采用，其余跳过；type必须精确声明编码格式并匹配服务端content-type响应头，否则导致加载失败或白屏。
<source></source> 标签不是用来直接播放或显示内容的，它本身不渲染、不触发加载，只起“声明备选资源”的作用；浏览器按顺序检查每个 <source></source>，遇到第一个能支持的就停，其余跳过——所以顺序、type 值是否准确、格式是否真被支持，这三点直接决定你的音视频能不能播、图片会不会白屏。
为什么 <source></source> 加了还是报错“Not supported”
常见错误是把 type 写成文件后缀或瞎填，比如 type="video/mp4" 看似合理，但若服务器没返回正确的 Content-Type 响应头（实际返回 text/plain），浏览器仍会拒绝加载；另一个高频坑是 MP4 容器里用了浏览器不支持的编码（如 H.265/HEVC），虽然 type 对了，但解码失败，结果和没写 <source></source> 一样。
- 用浏览器 DevTools 的 Network 面板确认每个
src对应请求的Content-Type响应头是否匹配type属性 - MP4 文件优先用 H.264 编码（
avc1.42E01E类），避免 H.265；WebM 用 VP9，Ogg 用 Theora + Vorbis - 不要依赖后缀判断：一个
.mp4文件如果封装了 AV1 视频流，type="video/mp4"仍可能被忽略
<source></source> 在 <picture></picture> 里怎么配合 srcset 和 sizes
在 <picture></picture> 中，<source></source> 不再只比格式，还要比“谁更适配当前视口+设备像素比”，这时 media 和 srcset 才真正协同工作；srcset 里的每个 URL 后必须跟宽度描述符（如 1x、2x 或 320w），否则浏览器无法计算密度匹配。
-
media="(max-width: 768px)"匹配的是 CSS 媒体查询，不是 JS 的window.innerWidth，注意单位和括号闭合 -
sizes必须出现在<img>上，不能放在<source></source>里；它的值要和media逻辑对得上，比如sizes="(max-width: 768px) 100vw, 50vw" - 所有
<source></source>都不匹配时，才 fallback 到<img src>，所以<img>是兜底，不是备选
浏览器怎么选 —— 顺序、type、preload 三者关系
浏览器对 <source></source> 的选择是纯同步、自上而下的：先看 media 是否满足（<picture></picture> 场景），再看 type 是否识别（<video>/<audio></audio></video> 场景），都不拦着就发请求；preload 属性由父级 <video></video> 或 <audio></audio> 控制，<source></source> 自身没有 preload 属性，也不会触发预加载。
- 把兼容性最广的格式（如 MP4/H.264）放在最上面，别为了“新格式优先”把 WebM 放第一，结果 Safari 直接跳过
- 加
preload="metadata"可让浏览器只拉头部信息，快速判断能否播，避免全量下载失败格式 - 服务端开启 HTTP/2 或 HTTP/3 能缓解多
<source></source>并发请求的延迟，但无法改变“只选一个”的行为逻辑
最容易被忽略的一点：你写的 type 值再标准，如果 CDN 或 Nginx 没配对的 MIME 类型映射，浏览器拿到的仍是 application/octet-stream，那整个 <source></source> 就形同虚设。上线前务必 curl 测响应头。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
