<source>的type属性不能随便写，因为浏览器不依赖文件后缀而依赖type值决定是否加载资源；必须使用标准MIME类型（如audio/mpeg而非audio/mp3），且需与服务器返回的Content-Type响应头逐字符一致，否则会导致静音、跳过或静默丢弃。
为什么 <source> 的 type 属性不能随便写
浏览器不会凭文件后缀猜格式，type 是它决定是否加载该资源的关键依据。写错或不写，可能导致音频不播放、静音、或直接跳过该 <source>。
-
type必须是标准 MIME 类型，比如"audio/mpeg"（不是"mp3"或"audio/mp3"） - 常见对应关系：
"audio/mpeg"→ MP3，"audio/ogg"→ Ogg Vorbis，"audio/wav"→ WAV，"audio/weba"→ WebM Audio - Chrome 和 Edge 对
audio/weba支持较好；Firefox 对audio/ogg更友好；Safari 基本只认audio/mpeg和audio/mp4（注意：不是audio/aac，而是"audio/mp4"，且需含 AAC 编码）
<source> 的 type 和实际文件编码不匹配会怎样
典型现象是：页面显示播放控件，点击播放没声音，控制台无报错，Network 面板里该资源状态码为 200 但 size 为 0 —— 这说明浏览器解析失败后静默丢弃了该源。
- MP3 文件若用
type="audio/ogg"，Firefox 会跳过；即使文件名是.ogg，但实际是 MP3 编码，也会失败 - 用
ffprobe -v quiet -show_entries format=format_name file.mp3可确认真实编码格式 - WebM 容器里的 Opus 音频应写
type="audio/webm"（不是"audio/opus"），因为浏览器按容器识别，而非内部编解码器
多个 <source> 标签的顺序和 fallback 逻辑
浏览器从上到下依次尝试每个 <source>，遇到第一个 type 被支持且资源可加载的就停止，后续全部忽略。顺序错了，可能绕过更小更快的格式。
- 推荐顺序：
audio/webm（现代、高压缩）→audio/ogg（Firefox 友好）→audio/mpeg（兼容 Safari/旧 IE） - 不要把
audio/mpeg放最前，否则 Chrome 也会加载 MP3，错过更优的 WebM -
<audio>内部的纯文本（如Your browser does not support the audio element.）仅在所有<source>都失败时才显示，不是“兜底内容”，而是彻底 fallback
如何验证 type 是否生效
别只看能不能播，要看浏览器到底选了哪个源 —— 这直接影响带宽和首帧时间。
立即学习“前端免费学习笔记（深入）”；
- 打开 DevTools → Network → 点击音频资源 → 查看
Content-Type响应头，必须与<source type="...">一致 - 在 Elements 面板中右键
<audio>→ “Break on” → “attribute modification”，然后监听src变化，能观察到浏览器内部切换逻辑 - 用
document.querySelector('audio').currentSrc在控制台运行，返回的实际 URL 就是最终被选用的<source>
真正容易被忽略的是服务器响应头：即使 type 写对了，如果服务端返回的 Content-Type 不匹配（比如 MP3 文件返回 text/plain），浏览器照样拒收。这点比前端标签还关键。
