核心是顺序、type精确性与服务端匹配：MP3必须首位且type="audio/mpeg"，OPUS/M4A次之并带codecs声明，WAV兜底；type须与Content-Type逐字符一致，且服务器需支持Range请求和CORS。
用 <source> 给 <audio> 提供多格式，核心就三点：顺序要对、type 要准、服务器要配得上。不是“写了就能播”，而是浏览器按顺序挑第一个它真能解码的——挑错了，后面再好也白搭。
source 顺序决定谁能被加载
浏览器从上到下逐个试 <source>，遇到第一个 canPlayType() 返回 "probably" 的就停，其余全跳过。所以必须把兼容性最广、解码最稳的放最前：
-
MP3 放第一位：全平台原生支持，
type="audio/mpeg"（注意不是audio/mp3） -
OPUS 或 M4A 放第二位：Chrome/Firefox 优先解码 OPUS（体积小、音质好），Safari 对
audio/ogg; codecs=opus支持已稳定；M4A（AAC-LC 编码）在 Safari 上比 MP3 更省带宽 -
WAV 放最后兜底：无损但文件大，仅用于极少数禁用压缩格式的内网环境，
type="audio/wav"
type 属性必须精确到编码层
只写 type="audio/ogg" 不够，浏览器可能发起请求却静默失败。真正起作用的是带 codecs 的完整声明：
- MP3：
type="audio/mpeg" - OPUS 封装在 OGG 容器：
type="audio/ogg; codecs=opus" - M4A（AAC-LC）：
type="audio/mp4; codecs=mp4a.40.2" - WAV：
type="audio/wav"
验证方法：打开控制台运行 Audio.canPlayType('audio/ogg; codecs="opus"')，返回 "probably" 才算可靠。
立即学习“前端免费学习笔记（深入）”；
服务端配置不能漏
前端写得再对，服务端没配好照样播不了：
-
Content-Type 响应头必须和
type值逐字符一致，比如audio/ogg; codecs=opus对应Content-Type: audio/ogg，不能是application/octet-stream - 必须支持 Range 请求：否则 Safari 和部分 Android WebView 无法拖动进度条，甚至卡在 loading 状态
-
跨域音频需 CORS 头：
Access-Control-Allow-Origin: *，不然 Safari 直接拒绝解码，还不报错 - Nginx 示例配置：
add_type audio/ogg .opus;、add_type audio/mp4 .m4a;、add_type audio/mpeg .mp3;
别踩这些常见结构坑
<source> 是 <audio> 的直接子元素，结构错一点就整个失效：
- 不能同时写
<audio src="...">和<source>，二者互斥 -
<source>必须在<audio>开始标签之后、结束标签之前，且中间要有降级文字，比如“您的浏览器不支持音频播放” - 本地开发别用
file://协议测试——type匹配逻辑会失效，务必走http://或https:// - 路径大小写、404、跨域问题不会报错，只会静默跳过，建议逐个在新标签页打开
src验证可访问性
