浏览器按顺序检查source的type属性是否被支持且实际可解码，首个两者均满足的被选用；type缺失或错误会导致跳过该source，即使文件存在。
为什么必须写type属性，不写就失效
浏览器不会根据文件后缀判断格式，只看type属性是否匹配其支持的 MIME 类型。没写type时，即使src="video.mp4"，Safari 也可能跳过它直接 fallback 到下一个或黑屏。
常见错误现象：Network 面板只看到一个请求，但视频不播；DevTools 控制台无报错，播放器卡在 loading 状态。
-
type值要精确：用video/mp4，别写video/mpeg或漏掉video/前缀 - 含编码器时必须带
codecs参数，例如type="video/webm; codecs="vp9""，否则 Chrome 可能拒绝加载 - iOS Safari 强制要求首个
<source></source>的type必须是 H.264 MP4（即video/mp4），否则静音、禁止自动播放，甚至抛NotAllowedError
多个的顺序不是“最优选”，而是“第一个可用”
浏览器按 DOM 中出现顺序逐个检查：type是否识别 → 资源 HTTP 状态是否为 200 → 是否能解码并播放成功。任意一环失败，才试下一个。它不比较清晰度、码率或压缩效率。
典型翻车场景：把webm放最前，但用户用 Safari（不支持 webm），又没配type，结果连试都不试，直接 fallback 到<video></video>的src或显示兜底文字。
立即学习“前端免费学习笔记（深入）”；
- 兼容性排序应为：
mp4 (H.264)→webm (VP9)→mp4 (AV1)（注意：AV1 的type需写video/mp4; codecs="av1"，且仅 Safari 16+ 支持） - 不要指望
media="(min-width: 768px)"让小屏设备“跳过高清源再加载标清”，它只是过滤候选列表——被media排除的<source></source>根本不会发请求 - 用
curl -I https://xxx.mp4确认响应头Content-Type: video/mp4，否则等于没写type
在里用和在
<picture></picture>中的<source></source>核心是响应式图像选择，依赖media + srcset + sizes三者协同；而<video></video>里的<source></source>只管格式兼容，media仅做初步筛选，不参与分辨率适配。
误用media会导致移动端加载不到合适资源：比如写了<source media="(min-width: 1024px)" src="hd.mp4"></source>，手机端这个<source></source>直接被忽略，若后面没配移动友好的 MP4，就会 fallback 到低质源或失败。
-
<picture></picture>中<source></source>的type用于格式协商，media用于条件激活，srcset提供多尺寸/密度选项 -
<video></video>中media只决定“当前是否参与竞争”，最终播哪个仍由顺序 +type+ 可解码性决定 - 真要做自适应码率（ABR），得上 HLS 或 DASH，靠 JS +
MediaSource控制，<source></source>本身无此能力
检查是否生效的三个实操动作
别猜，直接看浏览器行为。很多问题不是代码写错，而是资源本身或服务配置不匹配。
- 打开 DevTools →
Network面板，过滤media，观察实际发出的请求：只有一条？说明前一个<source></source>被接受了；一条都没？检查type拼写或media条件是否全不满足 - 右键视频 → “检查元素”，确认
<source></source>节点在 DOM 中存在且位置正确；若被 JS 动态插入，要等插入完成后再观察 Network - 用
curl -I验证每个srcURL 的响应头：Content-Type必须与type属性严格一致，HTTP 状态码必须是 200，且文件不能损坏（如 MP4 缺关键帧会导致静默失败）
mp4文件可能确实是 AV1 编码，但type="video/mp4"会让旧版浏览器当成 H.264 去解，结果失败；而你写的type="video/mp4; codecs="av1""又可能被 Safari 15 忽略——这种细节不验证，光调顺序没用。 
