在HTML5中，我们常说的play函数其实是指HTMLMediaElement接口上的play方法，它定义在video和audio元素之上。这个方法本身并不负责解析或解码媒体，它的作用仅仅是通知浏览器开始播放当前已关联并加载的媒体资源。因此，play能播放什么格式，完全取决于浏览器对该媒体元素所指定资源的容器与编码支持能力，而不是play方法有什么格式白名单。
从底层来看，当开发者写下一段如<video src="movie.webm">的代码并调用play时，浏览器会先检查自身媒体框架是否注册了webm容器及对应编解码器。若不支持，资源会在加载阶段失败，play返回的Promise会被拒绝，并抛出NotSupportedError。这意味着讨论play支持的格式，本质上是在讨论浏览器媒体流水线的解码兼容性。
一、主流浏览器支持的容器与编码组合
虽然HTML5规范没有强制规定必须支持哪些格式，但经过多年演进，行业形成了相对固定的兼容基线。最常见的三种组合是MP4、WebM和Ogg，它们各自绑定了不同的编解码方案。理解这些组合有助于我们在提供资源时做出正确选择。
MP4容器通常封装H.264视频与AAC音频，这是兼容性最广的方案，桌面和移动端几乎所有现代浏览器都支持。WebM容器多使用VP8或VP9视频搭配Vorbis或Opus音频，在Chrome、Firefox中表现优秀，但Safari长期支持较弱。Ogg容器常带Theora视频与Vorbis音频，主要在开源浏览器中受支持，IE系列完全不支持。下面用表格列出常见环境的支持差异：
| 浏览器 | MP4(H.264+AAC) | WebM(VP9+Opus) | Ogg(Theora) | MP3音频 |
|---|---|---|---|---|
| Chrome桌面 | 支持 | 支持 | 支持 | 支持 |
| Firefox桌面 | 支持 | 支持 | 支持 | 支持 |
| Safari桌面/iOS | 支持 | 部分新版本 | 不支持 | 支持 |
| Edge | 支持 | 支持 | 支持 | 支持 |
| 旧版IE11 | 支持 | 不支持 | 不支持 | 支持 |
从表中可以看出，若希望play方法在绝大多数环境顺利执行，优先提供MP4是最稳妥的。但在带宽敏感场景，WebM的VP9编码压缩率更高，适合Chrome用户群。我们需要用特性探测而非猜测来写代码。
二、使用canPlayType提前判断格式可用性
为了避免play方法因格式不支持而返回被拒Promise，HTML5提供了canPlayType函数。它接收一段MIME类型及编解码参数描述的字符串，返回probably、maybe或空字符串。空字符串代表不支持，另两个值代表不同程度的可播放信心。注意canPlayType不会实际加载文件，只做静态能力询问。
下面示例展示如何在调用play前做安全检测。我们使用audio元素探测MP3与WebM音频，再根据结果设置src并播放。这种方式能把格式错误隔绝在播放动作之前，提升用户体验。
// 创建音频元素用于格式探测
var audio = document.createElement('audio');
// 检测MP3格式支持情况
var mp3Support = audio.canPlayType('audio/mpeg');
// 检测WebM音频支持情况
var webmSupport = audio.canPlayType('audio/webm; codecs="vorbis"');
if (mp3Support !== '') {
audio.src = 'https://ipipp.com/media/sample.mp3';
console.log('使用MP3格式');
} else if (webmSupport !== '') {
audio.src = 'https://ipipp.com/media/sample.webm';
console.log('使用WebM格式');
} else {
console.log('当前浏览器不支持常规网络音频格式');
}
// 安全调用play，捕获可能的Promise拒绝
var playPromise = audio.play();
if (playPromise !== undefined) {
playPromise.then(function() {
console.log('播放已启动');
}).catch(function(err) {
console.log('播放被拒绝：' + err.message);
});
}
上述代码中的canPlayType参数是带codecs字段的，这比单纯写audio/webm更准确，因为WebM可能搭配不同编码。实践中建议写明编码，减少maybe误判。同时play返回Promise是HTML5后期规范补充，旧浏览器可能返回undefined，因此做了存在性判断。
三、用多source标签实现自动降级
除了用JS探测，HTML层面也提供了原生方案：在video或audio内部放置多个source标签，浏览器会按顺序尝试其src，直到找到能播放的格式才停止。此时play方法只需针对父级媒体元素调用一次，格式选择由浏览器完成。这大幅简化了兼容代码。
以下示例展示video元素如何使用多source。注意source标签本身不参与DOM播放控制，仅声明候选资源；type属性里的codecs信息帮助浏览器跳过明显不支持的项，加快选择。若所有source都失败，元素会触发error事件。
<video id="player" controls>
<source src="https://ipipp.com/video/movie.mp4" type="video/mp4; codecs='avc1.42E01E, mp4a.40.2'">
<source src="https://ipipp.com/video/movie.webm" type="video/webm; codecs='vp9, opus'">
<source src="https://ipipp.com/video/movie.ogv" type="video/ogg; codecs='theora, vorbis'">
您的浏览器不支持HTML5视频播放
</video>
<script>
var video = document.getElementById('player');
var p = video.play();
if (p && p.catch) {
p.catch(function(e) {
console.warn('自动播放受限或格式全不支持：' + e.name);
});
}
</script>
这段代码把格式兼容压力交给了浏览器内核。但要注意，移动端iOS的Safari即使有多source，也只会用它能解码的第一个，若把webm放前面而它不支持，它会直接跳过而不会回退到mp4，部分旧版本存在该限制。因此推荐把兼容性最好的mp4放在首个source。
四、常见误区与play失败排查
很多初学者以为play函数有参数能指定格式，实际上play只接受可选的playbackRate或对象参数（如video.play({ muted: true })"这样的写法其实是在某些浏览器扩展中用于控制自动播放策略），与媒体格式无关。格式必须在资源加载前确定。另一个误区是认为只要文件后缀对就能播，其实服务器返回的Content-Type错误也会导致canPlayType判断失效。
当play返回拒绝时，优先排查四件事：一是资源MIME与文件实际编码是否匹配；二是是否触犯浏览器自动播放策略（未静音的视频在无交互时被拦）；三是source顺序是否合理；四是跨域资源是否带了正确CORS头。把这些前置条件处理好，play的兼容性就不再是黑盒。
总结来说，HTML5的play方法本身不挑格式，挑格式的是浏览器解码器。开发时结合canPlayType探测、多source降级与正确的服务器配置，才能让play在各类环境下稳定发声出画。
HTML5_playaudio_formatvideo_format修改时间：2026-08-08 22:36:36