标签本身不播放,仅按顺序提供备选资源;浏览器严格执行三步判断(type匹配→content-type逐字符一致→首帧解码),ios safari强制首个必须是h.264 baseline+aac-lc的mp4且type含精确codecs,否则静音或白屏。

<source></source> 标签本身不播放任何东西,它只是告诉浏览器“这里有几个备选资源,你按顺序挑一个能播的”。它的核心价值不是功能丰富,而是容错——没有它,<video></video> 或 <audio></audio> 就只能赌一个格式,赌输了就白屏或静音。
为什么必须用而不是只写video的src属性
直接在 <video></video> 上写 src 属性,等于放弃所有 fallback 能力:浏览器只试这一个文件,不支持就报错,不会往下找。而多个 <source></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></source>,且必须同时满足:
- 格式是 MP4 容器
- 视频编码是 H.264 Baseline Profile(不能是 Main 或 High)
- 音频编码是 AAC-LC
-
type属性完整写出 codecs,例如:video/mp4; codecs="avc1.42E01E, mp4a.40.2" - 该
<source></source>必须排在第一位;哪怕后面跟了完全合法的 WebM,它也根本不发请求
错误示例:<source src="vid.webm" type="video/webm"></source> 放首位 → 真机上无报错、无日志、无声无画。
media 属性在 video/audio 的 source 中完全无效
别被 <picture></picture> 带偏:media 属性对 <video></video> 或 <audio></audio> 内的 <source></source> 没有任何作用。Chrome、Firefox、Safari、Edge 全部忽略它——这不是 bug,是 HTML 标准明文规定的适用范围仅限 <picture></picture>。
常见误判来源:
- 本地用
file://协议开发,type匹配逻辑失效,行为混乱,误以为media“起了作用” - 看到多个
<source></source>并列,主观推断“写了 media 就会条件加载”,其实浏览器只看顺序 +type+ 实际解码能力
真要适配设备,得靠服务端 User-Agent 分流,或前端 JS 检测 MediaSource.isTypeSupported() 后动态插入 <source></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:// 才能验证真实行为。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











