canPlayType() 是唯一能反映浏览器真实解码能力的运行时判断方式，返回 "probably"、"maybe" 或空字符串；必须传标准 MIME 类型（如 "audio/mpeg" 而非 "audio/mp3"），且需在真机或 Safari 技术预览版实测，配合正确 顺序与服务器 Content-Type 响应头才能确保音频正常播放。
怎么用 canPlayType() 快速验证浏览器实际解码能力
只看浏览器版本号或查兼容表没用，canPlayType() 才是唯一能反映真实解码能力的运行时判断方式。它返回 "probably"、"maybe" 或空字符串，没有布尔值，也不能靠后缀名猜。
常见误操作：
- 传
"audio/mp4"—— Safari 会返回空，必须写成"audio/mp4; codecs="aac"" - 传
"audio/mp3"—— 错，MIME 类型是"audio/mpeg"，拼错就直接跳过 - 在 Chrome DevTools 模拟器里测 —— 编解码器判断常失真，必须用真机或 Safari 技术预览版
实操建议：写个最小 HTML，用 JS 创建 audio 元素后立刻调用 canPlayType()，把结果打到控制台或页面上，不依赖任何第三方库。
为什么顺序错了会导致所有格式都失效
浏览器从上到下逐个尝试 <source></source>，遇到第一个 canPlayType() 返回非空的就停止加载，后面的全被忽略。这不是 bug，是规范行为。
立即学习“前端免费学习笔记（深入）”；
典型错误写法（iOS Safari 直接卡死）：
<audio controls> <source src="a.ogg" type="audio/ogg"> <source src="a.mp3" type="audio/mpeg"> </audio>
正确顺序（按主流浏览器解码器支持广度降序）：
-
<source src="a.mp3" type="audio/mpeg"></source>—— 兼容最广，但注意 Safari 对 VBR MP3 偶有失败 -
<source src="a.opus" type="audio/opus"></source>—— Chrome/Firefox 支持好，体积小，适合网络受限场景 -
<source src="a.wav" type="audio/wav"></source>—— iOS Safari 对 PCM WAV 稳定，但仅作短提示音兜底
别把 .ogg 放最后——Firefox 能播，Safari 完全跳过，等于白写。
Network 面板里音频请求 200 却没声音？先查 Content-Type 响应头
路径对、格式对、标签也写了，但就是没声音？90% 是服务器没返回正确的 MIME 类型响应头。浏览器看到 text/plain 或空着，直接当文本扔掉，连解码器都不调用。
排查步骤：
- 打开 DevTools → Network → 点开那个音频请求 → 查看 Response Headers 中的
Content-Type - MP3 必须是
audio/mpeg，不是audio/mp3或application/octet-stream - OGG 必须是
audio/ogg，且文件需为 Vorbis 编码（用ffprobe a.ogg确认输出含Audio: vorbis）
本地开发别双击 HTML 文件打开 —— file:// 协议下 Chrome/Firefox 会屏蔽音频加载，改用 python3 -m http.server 8000 启服务。
如何避免“点击按钮没反应”这类静默失败
用户点按钮没声音，控制台也没报错？大概率是 play() 被浏览器策略中断，Promise reject 了，但你没监听。
关键防护点：
- 每个
audio实例维护独立的isPlayingOrLoading状态变量，连点时提前 return - 必须监听
error事件：audio.addEventListener('error', () => console.warn(`音频 ${audio.id} 加载失败`)) - 自动播放必须同时满足三条件：
muted+ 用户手势触发 +preload="metadata"，缺一不可
容易被忽略的是：iOS Safari 对反复切换 src 后调 play() 极其敏感，极易卡住或静音 —— 这不是代码问题，是平台限制，得用多个独立 <audio></audio> 标签解决。
