HTML5
很多开发者可能都踩过这个坑：在页面上放了一个 标签，文件后缀也对，但浏览器就是播不出来，或者干脆报个 MEDIA_ERR_DECODE 错误。问题出在哪？其实， 标签本身并不决定“支持什么格式”，真正起决定性作用的，是浏览器内核对于特定「容器 + 编码」组合的解码能力。换句话说，光看文件后缀名是没用的，文件内部的编码格式不对，一切白搭。
哪些「容器+编码」组合实际能播
那么，当前（以2026年中主流浏览器稳定版为例）到底哪些组合是“安全”的呢？实际情况可能比想象中要严格得多，并非所有同名后缀的文件都等价：
.mp3：浏览器通常只认 MPEG-1 Layer III 编码，并且采样率最好别超过 48 kHz。像 HE-AAC、MP3 Surround 或者混合了 CBR/VBR 码率的文件，很可能会直接静音或加载失败。.ogg：这个容器里，浏览器通常只识别 Opus（这是目前的首选推荐）或 Vorbis 编码。需要特别注意，如果把 FLAC 音频封装进 .ogg 容器，Chrome 等浏览器是会拒绝播放的。.wa v：支持范围非常窄，基本上只认 16-bit PCM little-endian 这种 CD 标准格式。像 μ-law、a-law 或者 IEEE 754 浮点型的 WA V 文件，主流浏览器一概不认。.m4a/.mp4：容器里必须包含 AAC-LC 或 ALAC 编码。如果是 HE-AAC v2、AAC-HE 或者 H.264 视频里的音频轨道，标签通常会直接跳过。
如何快速验证浏览器对某种格式的支持度？有个简单的方法，在开发者工具的控制台里执行：Audio.canPlayType('audio/ogg; codecs="opus"')
只有当返回值是 "probably" 时，才表示该格式大概率可用。
为什么顺序不能随便写
另一个关键细节是
来看几个实际的例子：
- 截至 Safari 17.5，它仍然不识别
audio/ogg类型。如果你把 .ogg 文件放在第一个 - Chrome 对
audio/mp4; codecs="aac"的识别优先级，通常低于audio/ogg; codecs="opus"。因此，为了获得最佳的压缩效率和音质，应该把 Opus 格式的源文件放在最前面。 - 如果把一个庞大的
.wa v文件放在第一位，虽然 Firefox 等浏览器支持播放，但用户不得不先下载完这个几 MB 甚至更大的文件，体验会非常糟糕。
综合兼容性和效率，一个比较推荐的 fallback 顺序是这样的：
服务端配置比前端代码还关键
话说回来，即使前端的 HTML 代码写得天衣无缝，如果服务端配置不到位，音频依然可能无法播放，表现为 404、静音或者一直卡在加载状态。以下几个服务端配置点，往往比写前端代码更关键：
- 精确的
Content-Type：HTTP 响应头里的Content-Type必须精确匹配音频格式。例如，一个 Opus 音频文件，如果服务端返回的是application/octet-stream（通用二进制流），而不是audio/ogg，就可能出问题。 - 开启 CORS：对于跨域加载的音频资源，服务器必须正确配置跨源资源共享（CORS）头部，否则 Safari 等浏览器会直接拒绝解码。
- 支持 Range 请求：服务器必须支持
Range请求头。这是实现音频缓冲、拖动进度条（controls）以及preload="metadata"（仅预加载元数据如时长）等功能的基础。如果不支持，进度条将无法拖动。 - 配置 MIME 类型映射：在 Nginx 或 Apache 等 Web 服务器中，需要显式地为音频文件后缀添加正确的 MIME 类型。例如，对于 .opus 文件：
add_type audio/ogg .opus;
最后提一个容易混淆的点：使用 .ogg 作为 Opus 编码文件的后缀，并声明 codecs="opus"，这是完全安全的通用做法。但如果你使用了 .webm 作为容器后缀，那么对应的 type 就应该改为 audio/webm; codecs="opus"。核心原则是：MIME 类型声明不必与文件后缀强绑定，但必须与文件内部的真实编码格式严格一致。
