结论： 标签必须按兼容性优先级顺序排列，每个需带精确 type（如 video/mp4; codecs="avc1.42E01E, mp4a.40.2"），且不能与 的 src 共存；浏览器仅尝试第一个可解码成功的 source，非“选最优”而是“选首个可用”，iOS Safari 更强制要求首源为 H.264 MP4。
直接给结论：用 <source></source> 标签按兼容性优先级顺序列出多个格式，每个必须带精确 type，且不能和 <video></video> 的 src 属性共存——浏览器只认第一个能解码成功的，不是“选最优”，是“选第一个可用”。
为什么写了但还是只加载第一个？
这不是 bug，是规范行为。只要第一个 <source></source> 的 type 被浏览器识别，且资源返回 HTTP 200，它就不会再往下请求其他 <source></source>。
- 常见误判：用
curl -I看到 MP4 返回 200，就以为没问题；但实际文件可能无关键帧、编码 profile 不对（比如 iOS Safari 拒绝 High Profile H.264），导致静默失败，界面卡在 loading 状态 - 检查 DevTools Network 面板：如果只看到一个视频请求，说明前一个
<source></source>已被接受；若没请求后续项，重点查第一个的Content-Type响应头是否匹配你写的type - 别信文件后缀：一个
xxx.mp4文件可能是 AV1 编码，type="video/mp4"会失效，必须写type="video/mp4; codecs="av1""（但注意 Safari 16+ 才支持）
MP4、WebM、AV1 的 type 怎么写才准确？
type 不是可选项，写错等于没写。浏览器靠它跳过不支持的格式，避免无效请求。
-
video/mp4; codecs="avc1.42E01E, mp4a.40.2"：H.264 Baseline + AAC-LC，iOS Safari 和几乎所有设备都认 -
video/webm; codecs="vp9, opus"：Chrome/Firefox/Edge 原生支持，Safari 16.4+ 开始支持 VP9 -
video/mp4; codecs="av01.0.05M.08"：AV1 编码 MP4，仅现代 Chrome/Firefox 支持，旧版 Safari 直接忽略该<source></source> - 绝对不要写
type="video/mp4"这种宽泛值——它无法帮浏览器提前过滤，可能触发额外请求
iOS Safari 对第一个有硬限制
iOS Safari（包括所有 WebKit WebView）强制要求：第一个可播放的 <source></source> 必须是 H.264 编码的 MP4，否则可能静音、禁止自动播放，甚至抛 NotAllowedError。
立即学习“前端免费学习笔记（深入）”；
- 哪怕你把 WebM 放第一位、MP4 放第二位，Safari 也会跳过 WebM（不支持），但因第一个候选失效，可能拒绝播放整个
<video></video> - 解决方案：MP4（H.264）必须排第一；WebM 次之；AV1 或其他新格式放最后，仅作现代浏览器锦上添花
- 不要用
media属性试图“隐藏”首源——它只控制是否参与候选，不改变顺序逻辑，反而可能导致小屏设备 fallback 到低质量源
fallback 文字和 error 监听不能少
所有 <source></source> 都加载失败时，<video></video> 内部的纯文本内容会显示；但这不够，极端情况（如网络中断、解码器崩溃）需要 JS 补位。
- 在
<video></video>结束标签前写一句简明提示，比如您的浏览器不支持此视频格式。，兼顾无障碍与旧浏览器 - 监听
error事件比依赖 fallback 更主动：const v = document.getElementById('myVideo');<br>v.addEventListener('error', () => {<br> console.warn('所有格式均不可用');<br> // 可加载备用 GIF、提示用户升级浏览器、或上报错误<br>}); - 避免用 JavaScript 动态插入
<source></source>：可能绕过浏览器原生格式探测逻辑，优先用静态 HTML 结构
最容易被忽略的点：type 值必须和实际文件编码完全一致，且顺序不可颠倒——不是“多给几个保险”，而是“按浏览器能力阶梯式试探”。任何想靠 <source></source> 实现运行时切换、自适应分辨率或音轨选择的思路，都超出了它的设计边界。
