真正落地的兼容方案核心是写对<source>、声明准确type、配齐服务器MIME、兜住用户交互；单个src易失败因浏览器仅凭Content-Type匹配type，iOS Safari会跳过无type的source导致静默失败。
audio 标签本身就能播，但“能播”不等于“在所有设备上稳定播”。真正落地的兼容方案，核心不是加更多 JS，而是把 <source> 写对、type 声明准、服务器 MIME 配齐、用户交互兜住。
为什么单个 src 属性大概率失败
浏览器不会解包 MP3 文件去判断它是不是真能播——它只看 type 值是否匹配响应头里的 Content-Type。省略 type 时，Chrome 可能碰巧加载成功，但 iOS Safari 会直接跳过该 <source>，导致 canplay 不触发、duration 为 NaN、控制台静默失败。
-
<source src="a.mp3">→ iOS 拒绝加载，无报错 -
<audio src="a.mp3" controls>→ Firefox 可能播一半卡住，Safari 直接不响应 - 多个
<source>但没写type→ 浏览器逐个发请求，遇到 404 就继续，直到超时
<source> 的 type 必须写对且顺序合理
type 不是可选项，是浏览器做格式匹配的唯一依据。写错就等于告诉浏览器“这不是音频”，它连解码器都不会调用。
- MP3 必须写
type="audio/mpeg"，不是audio/mp3 - OGG 必须用 Vorbis 编码（
ffprobe a.ogg确认含Audio: vorbis），写type="audio/ogg" - WAV 仅适合短提示音，别当主力 fallback；IEEE Float 编码的 WAV Chrome 直接拒
- 顺序很重要：把兼容性最强的放最前，浏览器从上到下匹配第一个支持的
type
推荐写法：
立即学习“前端免费学习笔记（深入）”；
<audio controls preload="metadata"> <source src="song.mp3" type="audio/mpeg"> <source src="song.ogg" type="audio/ogg"> <source src="sound.wav" type="audio/wav"> 您的浏览器不支持音频播放。 </audio>
本地开发和服务器部署的 MIME 类型必须配对
即使 <source> 全写对了，如果响应头里 Content-Type 是 text/plain 或空着，浏览器就把它当普通文本扔掉，根本不会尝试解码。
- Apache：在
.htaccess或虚拟主机配置中加AddType audio/mpeg .mp3、AddType audio/ogg .ogg - Nginx：在
types块里补audio/mpeg mp3;、audio/ogg ogg; - 本地开发别双击 HTML：Chrome/Firefox 在
file://协议下会禁掉音频加载，必须起服务，例如python3 -m http.server 8000 - 检查 Network 面板：确认音频请求返回 200，且响应头
Content-Type准确对应后缀和编码
autoplay 和 play() 调用必须满足用户手势条件
写了 autoplay muted 还不响？不是代码错了，是浏览器在等用户“点一下”。现代浏览器（含微信 iOS）强制要求首次音频播放必须由用户手势触发，否则 play() 返回被 reject 的 Promise，控制台报 The play() request was interrupted。
- 删掉
autoplay，改用按钮点击触发：button.addEventListener('click', () => audio.play().catch(e => {})) - 不要在
DOMContentLoaded或window.onload里调play()，100% 失败 - iOS Safari 更严：元素必须在视口内、未被
display: none或opacity: 0遮挡 - 静音自动播虽允许，但需确保
muted是布尔属性（不带值），且后续 JS 没改volume或取消muted
最容易被忽略的是：iOS 上 canplay 事件不可靠，设置 currentTime 必须等这个事件；而 Android 低版本 WebView 压根不抛 canplay，得直接设 currentTime 后调 play()。平台差异不是 bug，是必须适配的现实。
