浏览器按 dom 顺序依次尝试每个 ，首个能解码播放的即被采用，后续全部跳过；type 属性必须精确声明编码格式，否则将导致无效回退或额外请求浪费。
<source></source> 标签本身不决定“格式优先级”，浏览器按 DOM 顺序依次尝试每个 <source></source>，遇到第一个能解码播放的就停，后续全部跳过——顺序即优先级。
浏览器如何选择 source：只看顺序，不看文件大小或编码效率
浏览器不会预检所有 <source></source> 再挑“最优”的那个，而是从上到下逐个试加载、解码、触发 canplaythrough。一旦某个 src 成功进入可播放状态，就立刻使用它，其余 <source></source> 不再发起请求（除非出错后回退）。
- 即使第二个
<source></source>是更小的 WebM 文件，只要第一个 MP4 能播，浏览器绝不会主动切过去 - 如果第一个
type声明错误（比如写成type="video/mp4"但实际是 AV1 编码），浏览器可能误判为“支持”而加载失败，然后才试下一个 - 网络中断或 CORS 拒绝会导致当前
<source></source>触发error事件，才会继续往下走
type 属性写错或省略，会直接破坏回退逻辑
type 不是可选装饰，它是浏览器跳过不支持格式的唯一依据。没写 type 或写得过于宽泛（如 type="video/mp4"），浏览器只能靠实际加载+解码来判断是否支持，白白浪费一次请求和时间。
- 正确写法必须带
codecs参数，例如：type="video/mp4; codecs="avc1.42E01E, mp4a.40.2" - MP4 推荐用 H.264 + AAC；WebM 推荐
type="video/webm; codecs="vp9, opus"；避免用 VP8（已逐步淘汰） - 如果
type和实际文件编码不一致（比如文件是 AV1 却声明为 H.264），浏览器可能加载成功但解码失败，报MediaError.MEDIA_ERR_DECODE
多 source 场景下的常见错误现象
看似写了多个 <source></source>，但页面始终只加载第一个，或全部失败——大概率不是浏览器问题，而是以下某处踩坑：
- 所有
<source></source>的type都声明了同一编码（如全写avc1.64001F），但实际文件编码不匹配 - 路径写错或服务器未配置对应 MIME 类型（比如 .webm 文件返回
text/plain），导致type判断失效 - 第一个
<source></source>的src返回 404，但没监听error事件，用户看不到任何提示 - 在
<video preload="none"></video>下，部分浏览器对后续<source></source>的错误检测更迟钝
真正起作用的永远是「你写的顺序」+「浏览器实际支持的解码器」+「服务端返回的真实 MIME 和编码」三者交集；别指望浏览器自动优化，它只做最朴素的线性尝试。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
