用canplaytype()实测音频格式最可靠，返回"probably"表示大概率能播，"maybe"为风险，""即不支持；需创建audio元素逐个检测，且必须显式声明type属性。
用 canPlayType() 实测音频格式，不是看浏览器型号
浏览器是否能播某种音频，和它叫 Chrome 还是 Safari 几乎无关，关键在底层解码器是否启用。比如 Firefox 在某些 Linux 发行版里默认禁用 MP3 解码器，audio/mpeg 就会返回空字符串；Safari 17 仍不支持 audio/webm; codecs="opus"，哪怕你写了也跳过。别查 UA，直接调用 canPlayType()：
- 创建临时元素：
const a = new Audio() - 逐个检测：
a.canPlayType('audio/mpeg')、a.canPlayType('audio/mp4; codecs="aac"')、a.canPlayType('audio/ogg; codecs="vorbis"') - 结果只认
"probably"（大概率能播），"maybe"视为风险，""（空）就是不支持
注意：Firefox 对 audio/mpeg 的判断有时不准，建议补一手 new Audio().canPlayType('audio/mp3') 做交叉验证（虽然 MIME 类型不规范，但部分旧版 Firefox 会响应）。
多 <source></source> 必须带 type，否则 iOS Safari 直接静默失败
写成 <source src="sound.mp3"></source> 看似省事，但在 iOS Safari 里等于没写——它不会尝试加载，canplay 不触发，duration 是 NaN，控制台也不报错。必须显式声明 MIME 类型：
-
<source src="sound.mp3" type="audio/mpeg"></source>（MP3 正确写法） -
<source src="sound.m4a" type="audio/mp4; codecs=" aac></source>（M4A 推荐写法，带 codecs） -
<source src="sound.opus" type="audio/opus"></source>（Chrome/Firefox 支持，体积小，但 Safari 仍不支持）
顺序很重要：把 audio/mpeg 放最前，audio/mp4 次之，audio/opus 或 audio/wav 放最后。浏览器按 DOM 顺序尝试，第一个返回 "probably" 的就用它。
自动播放被拒时，play() 的 Promise 拒绝原因要分清
用户点击后调用 audio.play()，结果却静音或报错？别只 catch 一个 e，得区分三类错误：
-
NotAllowedError：自动播放策略拦截（常见于未满足 muted + 用户手势） -
NotSupportedError：所有<source></source>都不被支持（error.code === 4） -
AbortError：网络中断或资源加载失败（检查 Network 面板里音频请求是否 200）
实操建议：绑定 error 事件，打印 audio.error?.code 和 audio.currentSrc，再配合 Network 面板看具体哪个 source 失败。别依赖 canplay 判断就绪——它只表示元数据加载完，音频体可能还没到；真要等缓冲足够，用 canplaythrough，但首次播放延迟明显增加。
AudioContext 初始化失败常被忽略，但它影响 Web Audio 链路
如果项目用到了 AudioContext（比如混音、滤波、动态音量控制），光有 <audio></audio> 标签还不够。iOS Safari 和旧版 Android WebView 对 AudioContext 启动有额外限制：
- 必须由用户手势触发（如 click/touchend），不能在页面 load 时直接 new
- 需兼容写法：
const AudioCtor = window.AudioContext || window.webkitAudioContext - 初始化后检查关键方法是否存在：
ctx.createMediaStreamSource、ctx.decodeAudioData
一个容易被绕过的坑：iOS Safari 在后台标签页中会 suspend AudioContext，切回页面后需手动 resume() 才能继续播放。不处理的话，后续所有 start() 调用都静默失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
