audio标签必须显式声明type且与服务器content-type严格匹配，mp3用audio/mpeg、ogg用audio/ogg、wav用audio/wav；多格式按兼容性降序排列（mp3→ogg→wav）；移动端需用户手势触发play()，file://协议下需本地http服务。
audio标签不写就等于放弃兼容
只用<audio src="a.mp3" controls></audio>，在 Safari（尤其是 iOS）、旧版 Firefox、部分 Android WebView 里大概率静音、卡顿或完全不触发 canplay。浏览器不会报错，只是跳过加载——Network 面板里连请求都没有。
每个必须带正确的type，且和服务器Content-Type严格匹配
type不是可选项，也不是“写个大概就行”。写错或省略，Safari 直接忽略该 <source></source>，后续 fallback 失效。
-
MP3对应type="audio/mpeg"，不是audio/mp3（后者无效） -
OGG(Vorbis)对应type="audio/ogg"，确认文件编码是 Vorbis（用ffprobe a.ogg查） -
WAV推荐用type="audio/wav"，但仅作短提示音兜底；避免 IEEE Float 编码，Chrome 会拒绝 - 服务器响应头必须是
Content-Type: audio/mpeg等对应值，否则浏览器当文本处理，连解码器都不调用
多格式顺序决定 fallback 路径，别指望 JS 动态判断
浏览器按 DOM 顺序逐个尝试 <source></source>，找到第一个 canPlayType() 返回 "probably" 或 "maybe" 的就停。这个判断非常粗粒度，靠它选源不如静态排好序可靠。
- 把兼容性最广的放最前：
<source src="a.mp3" type="audio/mpeg"></source> - 其次加 OGG：
<source src="a.ogg" type="audio/ogg"></source>（Firefox/Chrome 友好，Safari 忽略） - 最后放 WAV：
<source src="a.wav" type="audio/wav"></source>（Safari 兜底，但体积大、加载慢） - OPUS（
audio/opus）可选，Chrome/Firefox 支持好、体积小，但 Safari 不支持，别放第一位
移动端自动播放失败？那不是代码问题，是规则限制
写了 autoplay muted 还不响，大概率是因为没过用户手势关。iOS Safari 和很多安卓 WebView 要求：首次 play() 必须发生在用户点击、触摸等交互事件回调内。
- 别在
load、canplay或页面初始化时直接调audio.play() - 正确做法：
button.addEventListener('click', () => audio.play().catch(e => console.warn('play rejected:', e))) - 即使
muted，微信 iOS WebView 仍可能要求首次触摸后才放行，别硬刚 - 本地开发用
file://协议时，Chrome 会直接禁用play()，必须起本地服务（如python3 -m http.server）
真正难的不是写几个 <source></source>，而是让每个 source 的 type、服务器 MIME、文件编码、加载时机、用户交互上下文全部对齐——漏一环，音频就哑了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
