<source>标签本身不播放，仅按顺序提供备选资源；浏览器严格执行三步判断（type匹配→Content-Type逐字符一致→首帧解码），iOS Safari强制首个<source>必须是H.264 Baseline+AAC-LC的MP4且type含精确codecs，否则静音或白屏。
<source> 标签本身不播放任何东西，它只是告诉浏览器“这里有几个备选资源，你按顺序挑一个能播的”。它的核心价值不是功能丰富，而是容错——没有它，<video> 或 <audio> 就只能赌一个格式，赌输了就白屏或静音。
为什么必须用而不是只写video的src属性
直接在 <video> 上写 src 属性，等于放弃所有 fallback 能力：浏览器只试这一个文件，不支持就报错，不会往下找。而多个 <source> 是显式声明“我准备了多个版本”，浏览器会严格按顺序执行三步判断：
- 检查
type是否被canPlayType()返回"probably"或"maybe" - 发起 HTTP 请求，要求响应头
Content-Type与type属性逐字符一致（比如video/mp4; codecs="avc1.42E01E, mp4a.40.2"中的空格、逗号、引号都不能错） - 尝试解码视频第一帧——Network 面板看到 200 ≠ 播得通；iOS Safari 就常卡在这一步静音
iOS Safari 对顺序和type的硬性要求
这是最常翻车的点：iOS Safari（包括所有 WebKit WebView）根本不会 fallback。它只认第一个 <source>，且必须同时满足：
- 格式是 MP4 容器
- 视频编码是 H.264 Baseline Profile（不能是 Main 或 High）
- 音频编码是 AAC-LC
-
type属性完整写出 codecs，例如：video/mp4; codecs="avc1.42E01E, mp4a.40.2" - 该
<source>必须排在第一位；哪怕后面跟了完全合法的 WebM，它也根本不发请求
错误示例：<source src="vid.webm" type="video/webm"> 放首位 → 真机上无报错、无日志、无声无画。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
media 属性在 video/audio 的 source 中完全无效
别被 <picture> 带偏：media 属性对 <video> 或 <audio> 内的 <source> 没有任何作用。Chrome、Firefox、Safari、Edge 全部忽略它——这不是 bug，是 HTML 标准明文规定的适用范围仅限 <picture>。
常见误判来源：
- 本地用
file://协议开发，type匹配逻辑失效，行为混乱，误以为media“起了作用” - 看到多个
<source>并列，主观推断“写了 media 就会条件加载”，其实浏览器只看顺序 +type+ 实际解码能力
真要适配设备，得靠服务端 User-Agent 分流，或前端 JS 检测 MediaSource.isTypeSupported() 后动态插入 <source>。
音频的兼容要点比视频更简单但仍有坑
音频格式支持广，但顺序和 type 依然关键：
- MP3 必须放第一位：
type="audio/mpeg"（不是audio/mp3） - Ogg 可作为第二顺位：
type="audio/ogg"，但注意 Safari 直到 17.4 才开始稳定支持 - WAV 体积大，仅作兜底：
type="audio/wav"，不推荐线上使用 - 所有
type值必须与服务器返回的Content-Type响应头完全一致，否则请求发出去也静默失败
真正容易被忽略的是：本地开发时用 file:// 协议，type 判断直接失效，此时无论怎么写都可能播不通——必须走 http:// 或 https:// 才能验证真实行为。
