浏览器按dom顺序选择首个type被支持且实际编解码器兼容的source，不回退重试；type必须为标准mime类型并精确匹配编码（如video/mp4; codecs="avc1.42e01e, mp4a.40.2"），否则跳过加载。
<source></source> 不是“备用加载开关”，而是浏览器格式探测的输入列表——它只按顺序试一次，选中即停，不会回退或重试。
浏览器怎么挑第一个能播的 <source></source>
挑的过程分两步：先看 type 声明是否被支持（比如 video/webm），再检查实际文件能否被当前设备解码（比如 VP9 编码在旧 Android 上可能失败）。哪怕第二个 <source></source> 文件更小、更清晰，只要第一个声明了且浏览器认为“能处理”，就直接用它。
- 顺序决定命运：把兼容性最广的放最前，比如
<source src="vid.mp4" type="video/mp4"></source>必须在<source src="vid.webm" type="video/webm"></source>前面 -
type写错等于没写：写成"mp4"或"video.mp4"，浏览器直接跳过该<source></source>，Network 面板里根本看不到请求 - iOS Safari 有硬规则：首个
<source></source>必须是 H.264 Baseline + AAC-LC 的 MP4，且type要带 codecs，如type="video/mp4; codecs="avc1.42E01E, mp4a.40.2""，否则静音或报NotAllowedError
type 属性写什么才真正起作用
type 不是可有可无的装饰，它是浏览器过滤 <source></source> 的第一道闸门。值必须是标准 MIME 类型，且和实际文件编码严格匹配。
- MP4：优先用
type="video/mp4"；若要精确控制，得查真实编码（用ffprobe），比如 H.265 就得写type="video/mp4; codecs="hev1.1.2.L93.90""，不能套用 H.264 的 codecs 字符串 - WebM：用
type="video/webm"最稳妥；硬写codecs="vp9, opus"反而容易因浏览器版本差异被跳过 - Ogg：仅作降级兜底，
type="video/ogg"即可，现代浏览器基本不走这条路 - 服务器响应头
Content-Type和type不一致时，浏览器以type为准；但若type正确而实际文件编码不匹配，会触发error事件，而非自动 fallback 到下一个
为什么换了 <source></source> 还是不生效
DOM 更新不等于播放器重载。改了 <source></source> 列表后，浏览器不会自动重新加载视频流——它仍用着旧缓冲、旧元数据。
- 必须显式调用
video.load()，否则界面卡在上一帧，时间轴也不更新 - 推荐安全流程：
video.pause()→ 替换<source></source>子节点 →video.load()→ 绑定loadedmetadata事件再play() - 别用
video.src = "xxx"绕过<source></source>，这样会丢失多格式 fallback 能力；也别用 JS 动态插入<source></source>，部分浏览器可能跳过原生格式探测逻辑 - 验证是否真生效：打开 DevTools → Network → 播放视频，看实际发出的请求是不是你期望的那个
src
最容易被忽略的是第一个 <source></source> 的 type 和实际编码是否严丝合缝——差一个空格、少一个引号，iOS Safari 就拒绝解码，且控制台不报错，只留一片黑屏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
