浏览器按 dom 顺序线性尝试 ，首个可解码播放的即被采用，后续全部跳过；顺序错误、type 属性缺失或不匹配、服务端 mime 不一致，均会导致回退链断裂。
顺序就是优先级，浏览器不会“挑最优”，只按 DOM 顺序线性尝试，第一个能解码播放的就用它。
为什么顺序不能随便写
浏览器不预检所有 <source></source>，而是从上到下逐个发起请求、加载、解码、等待 canplaythrough。一旦某个 src 成功进入可播放状态，后续所有 <source></source> 都被跳过——哪怕第二个文件更小、编码更高效，也绝不会主动切换。
- 第一个
<source></source>的type写错（比如声明video/mp4; codecs="avc1.42E01E"，但实际是 AV1 编码），浏览器可能误判为“支持”，加载后报MediaError.MEDIA_ERR_DECODE才试下一个 - 若第一个
src返回 404 或 CORS 拒绝，会触发error事件，才继续往下走 - 在
<video preload="none"></video>下，部分浏览器对后续<source></source>的错误感知更迟钝，容易卡住
视频格式推荐顺序与 type 写法
不是“越新越好”，而是按**当前全平台解码器覆盖广度**排：MP4(H.264+AAC) 最稳，WebM(VP9+Opus) 次之，Ogg 基本可删。
-
<source src="vid.mp4" type="video/mp4; codecs=" avc1.42e01e mp4a.40.2></source>—— H.264 Baseline + AAC-LC，iOS/Safari/Android WebView 全兼容 -
<source src="vid.webm" type="video/webm; codecs=" vp9 opus></source>—— Chrome/Firefox/Edge 原生支持，Safari 16.4+ 开始支持 VP9 - 避免用
type="video/mp4"这种宽泛写法：浏览器无法提前跳过，会发一次无效请求再失败 - 服务器返回的 Content-Type 必须和
type属性严格一致，比如.webm文件不能返回text/plain
音频多格式回退怎么排才不踩坑
iOS 是最大变量：它完全不支持 audio/ogg 和 audio/flac，且必须由用户手势触发播放。所以 MP3 要放第一位，不是“保底”而是“主力”。
-
<source src="track.mp3" type="audio/mpeg"></source>—— 注意是audio/mpeg，不是audio/mp3（后者部分 Safari 版本直接忽略） -
<source src="track.wav" type="audio/wav"></source>—— 未压缩 PCM，体积大，仅作极简 fallback，别指望移动端用它 - 所有
src路径必须真实可访问；404 时浏览器静默跳过，Network 面板里看不到明显报错，容易误判为“没回退” - 别在
<audio></audio>外部写<source></source>：控制台会报The element has no supported sources，播放器直接空白
type 属性写错或缺失的后果最直接
type 不是装饰，它是浏览器跳过不支持格式的唯一依据。写错 = 白白浪费一次网络请求 + 解码尝试 + 用户等待时间。
- 漏写
type：浏览器只能靠加载+解码判断是否支持，全部<source></source>都可能被试一遍 -
type="video/mp4"→ 错，应带codecs参数，如avc1.42E01E -
type="video/mpeg"→ 错，这是给.mpeg文件用的，不是 MP4 - 服务端 MIME 类型不匹配（如 Nginx 未配置
.webm的video/webm）会导致type判断失效
真正起作用的是「你写的顺序」+「浏览器实际解码器能力」+「服务端返回的真实 MIME 和编码」三者交集。别依赖浏览器“聪明”，它只做最朴素的线性尝试——顺序写错、type 写错、路径或 MIME 错一个，整个回退链就断了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
