audio/mpeg 是 mp3 的唯一合法 type 值，写成 audio/mp3 或 mp3 均失效；浏览器仅认 iana 注册 mime 类型，且必须与服务器返回的 content-type 逐字符一致，否则静默跳过该 source。
audio/mpeg 是 MP3 的唯一合法 type 值
写 type="audio/mp3" 或 type="mp3" 都会失效，Safari 和 Firefox 直接跳过该 <source></source>，哪怕文件本身是标准 MP3。浏览器只认 IANA 注册的 MIME 类型，MP3 对应的是 audio/mpeg —— 注意不是 audio/mp3，也不是 audio/x-mpeg。
常见翻车点：
- 后端返回的 Content-Type 是
audio/mp3，但 HTML 里写了type="audio/mpeg"→ 不匹配，静默丢弃 - 本地开发用
file://协议时，type 判断完全失效，所有格式都可能被加载（但实际解码仍可能失败） - 用 curl 检查响应头：
curl -I https://example.com/song.mp3，确认返回的Content-Type: audio/mpeg逐字符一致
WebM 音频必须用 audio/webm，不是 audio/opus
浏览器按容器识别格式，不是按内部编解码器。即使 WebM 文件里装的是 Opus 编码音频，type 也必须写 audio/webm，写成 audio/opus 或 audio/webm; codecs="opus" 会导致 Chrome 跳过、Firefox 忽略、Safari 完全不请求。
验证真实封装格式：
- 运行
ffprobe -v quiet -show_entries format=format_name song.webm，输出应为webm - 如果输出是
matroska，说明是通用 MKV 容器，不能用audio/webm；得重编码或改用audio/x-matroska（但支持极差，不推荐） -
audio/webm在 Chrome、Edge、Firefox 中表现稳定；Safari 16.4+ 开始支持，旧版 Safari 会直接跳过
多个 source 的顺序决定是否真能 fallback
浏览器不是“选最优”，而是从上到下找第一个 type 被支持 *且* 实际文件可解码的源。顺序错了，就等于没写其他格式。
推荐顺序（兼顾兼容性与体积）：
-
<source src="song.mp3" type="audio/mpeg"></source>—— 放最前，iOS Safari / 旧 Android 必须靠它启动 -
<source src="song.webm" type="audio/webm"></source>—— 现代浏览器优先用，体积小、音质好 -
<source src="song.ogg" type="audio/ogg"></source>—— 仅 Firefox 旧版本需要，可省略
错误顺序示例：<source src="song.webm"></source> 放第一位 → Safari 不发请求，直接卡住，后续 MP3 根本不尝试。
type 写错时根本不会报错，只会静默失败
控制台不报错、Network 面板看到 200、播放控件正常显示——但点击播放没声音，document.querySelector('audio').currentSrc 返回空字符串。这是最典型的 type 不匹配现象。
排查步骤：
- 打开 DevTools → Network → 点击音频资源 → 检查 Response Headers 中的
Content-Type是否和<source type=""></source>完全一致（包括大小写、空格、分号） - 在 Elements 面板中右键
<source></source>→ Break on → attribute modification，观察浏览器是否切换了src - 用
audio.canPlayType('audio/mpeg')在控制台运行，返回""表示浏览器根本不认这个 type
最容易被忽略的一点：MP3 文件若实际是 AAC 编码（比如 .m4a 重命名为 .mp3），type="audio/mpeg" 依然会失败——ffprobe 看的是真实编码，不是后缀名。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
