html解析器不参与格式选择，仅按顺序构建dom树；浏览器加载时才依据dom顺序、type与content-type严格匹配、实际帧可解码三者交集决定播放源。
HTML 解析器本身不参与 <source></source> 的格式选择，也不计算“匹配权重”——浏览器根本不会在解析阶段做任何格式优劣判断。
HTML 解析器只负责把 <source></source> 按顺序放进 DOM 树
Tokenizer 阶段把 <source src="a.mp4" type="video/mp4"></source> 当作一个起始标签令牌处理，Tree Construction 阶段把它作为 <video></video> 的子节点插入。此时没有任何解码、MIME 校验或兼容性评估发生；它只是个静态节点，和 <div> 没本质区别。
<p>所谓“优先级”完全由后续的媒体加载逻辑决定，而非解析器赋予。你改 DOM 顺序、删节点、JS 动态插入，只要最终结构是：</p>
<pre class="brush:php;toolbar:false;"><video><source src="h264.mp4" type="video/mp4; codecs=" avc1.42e01e mp4a.40.2><source src="vp9.webm" type="video/webm; codecs=" vp9 opus></source></source></video></pre>
<p>那浏览器就永远按这个顺序试，和解析时怎么建的树无关。</p>
<h3>
<code>type 属性在解析阶段不生效，只在加载时被读取
解析器会原样保留 type 值，但不会验证它是否合法、是否匹配文件实际编码、甚至不检查语法（比如漏引号、多空格）。这些全留到资源加载阶段才触发：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 如果
type写成video/mpeg（非法 MIME），浏览器加载时直接跳过该<source></source>，不发请求 - 如果
type="video/mp4"但服务端返回Content-Type: video/webm，两者逐字符不一致 → 浏览器忽略该<source></source>，哪怕文件能播 - 如果
type缺失，浏览器只能靠真实加载+解码来判断，白耗一次网络请求和时间
iOS Safari 在解析后立刻强制拦截非 H.264 首源
这不是解析阶段的行为，而是 WebKit 在 DOM 构建完成、进入媒体加载前的硬性策略：一旦发现 <video></video> 的第一个子 <source></source> 不满足 type="video/mp4; codecs="avc1.42E01E..."" 且实际编码为 H.264 Baseline，整个 <video></video> 就被标记为不可用——后续 <source></source> 根本不会进入加载队列，Network 面板里连请求都看不到。
这种拦截发生在解析之后、加载之前，不属于 HTML 解析器职责，但它是真实存在的“权重归零”机制：
- 其他浏览器：首个
<source></source>加载失败 → 触发error事件 → 尝试下一个 - iOS Safari：首个
<source></source>type 或编码不合规 → 直接放弃全部，不触发任何 error，也不加载后续
真正影响“选择结果”的三个环节不在解析器里
决定最终播哪个的，是这三步的交集，解析器只贡献了第一步的 DOM 顺序：
- DOM 顺序：谁在前谁先被试（解析器唯一贡献）
-
type + Content-Type 逐字符匹配：服务器响应头必须和
type值完全一致（HTTP 层） - 实际帧可解码：文件不能损坏、关键帧得存在、profile 得是 Baseline（解码器层）
最容易被忽略的是第三点：Network 面板看到 200 OK，DevTools Media 面板里却显示 decoder failed 或卡在 loading 状态——这时候你得用 ffprobe 查 profile，而不是去调 HTML 结构。
