浏览器加载<video>时按DOM顺序逐个检查<source>，首个满足HTTP状态、type匹配、Content-Type一致且可解码的即加载，后续全部跳过。
type属性决定浏览器是否跳过某个，不是“选最优”，而是“第一个能解码就停”
浏览器加载 <video> 时，不会预览所有 <source> 文件内容，也不会比较分辨率或码率。它只按 DOM 顺序逐个检查：HTTP 状态码是否为 200、type 是否被识别、响应头 Content-Type 是否与 type 值**逐字符一致**、文件能否被当前解码器处理。一旦满足全部条件，立刻加载并停止后续尝试——后面再高清、再小体积也完全不读。
- 写
type="video/mp4"而不带codecs，iOS Safari 可能加载成功但静音（因默认要求 H.264 Baseline + AAC-LC） - 服务器返回
Content-Type: audio/mpeg，但你写type="audio/mp3"→ Safari 直接跳过，不报错也不 fallback - 本地用
file://协议时，type判断逻辑失效，浏览器退化为仅看文件后缀，行为不可靠
不带 codecs 的 type 声明会放大兼容性风险
仅写 type="video/mp4" 看似省事，但 MP4 容器可封装 H.264、HEVC、AV1 等多种编码，而不同浏览器支持范围差异极大。比如 Chrome 支持 AV1，Safari 目前不支持；Edge 支持 HEVC，Firefox 默认不启用。没有 codecs 参数，浏览器只能靠试错——可能加载一个自己无法解码的 MP4，结果黑屏无声，且控制台无提示。
- 推荐写法：
type="video/mp4; codecs="avc1.42E01E, mp4a.40.2"（H.264 Baseline + AAC-LC，全平台安全） - WebM 推荐：
type="video/webm; codecs="vp8, vorbis"或"vp9, opus"（注意 Opus 音频需对应audio/opus） - 用开发者工具 Network 面板确认每个资源的实际
Content-Type响应头，而非依赖本地文件名
media 属性对 <source> 在 <video> 中基本无效
很多人误以为 media="(min-width: 768px)" 能让大屏设备加载高清源、小屏加载标清源。实际上，在 <video> 内，media 属性**被所有主流浏览器忽略**。它只在 <picture> 中起作用。写在 <video> 的 <source> 上，既不参与初始匹配，也不影响播放中切换。
- 想实现设备分辨率适配？只能靠服务端 User-Agent 判断 + 动态生成 HTML，或 JS 检测
window.innerWidth后手动设置<video>.src - 不要给多个
<source>设置相同type和media，行为未定义，多数浏览器取第一个 -
<source>上写的width、height、autoplay等属性完全被忽略，这些必须写在父级<video>上
真正影响性能的是首个匹配项的体积和解码开销
所谓“性能作用”，本质是避免浏览器浪费时间请求和解析不支持的格式。如果第一个 <source> 是 1080p WebM（Chrome 支持），而第二个是 480p MP4（Safari 支持），那么 Safari 会跳过第一个 404 或解码失败，再请求第二个——多一次 HTTP 请求 + 解析延迟。更糟的是，如果第一个 MP4 编码不兼容（如 HEVC），Safari 可能卡住数秒才放弃。
立即学习“前端免费学习笔记（深入）”；
- 把最广泛兼容的格式（H.264 MP4）放在最前面，能显著降低首帧渲染时间
- 避免把体积最大、编码最新的格式（如 AV1 MP4）放首位，除非你明确只服务支持它的环境
- CDN 缓存策略要针对每个
src独立配置，不同<source>的缓存 Key 不互通
<source>，其余只是备胎。别指望它智能择优，它只认“能跑就行”。 
