audio.canPlayType() 返回 "maybe" 实际无效，因浏览器实现不一且不保证支持；真实兼容性依赖 HTML 中 <source> 的严格 MIME 类型顺序和服务器正确配置 Content-Type。
audio.canPlayType() 返回 "maybe" 就等于没用
浏览器对 canPlayType() 的实现极不统一：Chrome 对 audio/ogg 可能返回 "probably"，Firefox 却返回 "maybe"，而 Safari 直接对 audio/ogg 返回空字符串。更糟的是，"maybe" 不代表“可能支持”，只代表“无法排除”，实际加载后仍大概率失败。
别拿它做格式决策依据。真实兼容性靠的是静态 <source> 顺序兜底，不是 JS 动态判断。
- 所有主流浏览器都严格按 DOM 中
<source>出现顺序尝试，第一个type匹配且服务器返回正确Content-Type的源才会被加载 -
canPlayType('audio/mpeg')在 Safari 返回"probably"，但在某些 iOS 版本里，若 MP3 是 VBR 编码，依然静音或卡在networkState === 0 - 想验证某格式是否真能播？直接写进 HTML，用 Network 面板看请求是否返回 200 +
Content-Type: audio/mpeg，而不是信 JS 返回值
type 属性写错一个字母就全盘失效
type="audio/mp3"、type="audio/x-mpeg"、type="audio/mp4"（用于 .m4a）全是错的。浏览器不会纠错，只会跳过该 <source>，且不报错、不警告，静默失败。
必须严格匹配 MIME 类型标准：
立即学习“前端免费学习笔记（深入）”；
- MP3 文件 →
type="audio/mpeg"（不是mp3） - OGG（Vorbis 编码）→
type="audio/ogg"（不是oga或ogv） - M4A（AAC 编码）→
type="audio/mp4"（不是audio/aac） - WAV（PCM 16-bit little-endian）→
type="audio/wav"（float 格式或 big-endian 会被 Safari 拒绝）
用 ffprobe file.mp3 确认编码，再配对 type；否则即使文件存在、路径正确，也白搭。
服务器 MIME 类型没配对，前端写得再全也没用
哪怕你写了三组 <source>、type 全对、路径全通，只要响应头里 Content-Type 是 text/plain 或空着，浏览器就当它是纯文本扔掉——连解码器都不会调用。
本地开发时，双击 HTML 文件走 file:// 协议，Chrome/Firefox 会直接屏蔽音频加载，必须起本地服务：
- Python 用户：
python3 -m http.server 8000 - Apache：
AddType audio/mpeg .mp3和AddType audio/ogg .ogg加到.htaccess或虚拟主机配置 - Nginx：在
types块里补audio/mpeg mp3;和audio/ogg ogg;
检查方式：打开 DevTools → Network → 点开音频请求 → 看 Response Headers 里的 Content-Type 是否精确匹配你写的 type 值。
iOS Safari 对 OGG 的“支持”是假象
Safari（包括 iOS）官方文档写“支持 OGG”，但实测中，即使 <source src="a.ogg" type="audio/ogg"> 写得完全正确，它也常跳过该源，转而尝试下一个——哪怕后面只有 WAV。这不是 bug，是 WebKit 的策略性忽略。
真正落地的顺序只能是：
- 第一顺位：
<source src="a.mp3" type="audio/mpeg">（兼容最广） - 第二顺位：
<source src="a.m4a" type="audio/mp4">（AAC 编码，Safari 最稳） - 第三顺位：
<source src="a.wav" type="audio/wav">（仅短提示音，确保 PCM 16-bit little-endian） - OGG 放最后或干脆不用——它在 Firefox/Chrome 有用，在 Safari 上基本是装饰
别指望靠 OGG 拉齐 Safari 兼容性，那是用错工具。
