应直接用 canPlayType() 在真实设备上测试音频格式兼容性，因其比查表更准更快；它依据 MIME 类型与编解码器组合返回 "probably"、"maybe" 或空字符串，但需注意正确写法（如 audio/mpeg 非 audio/mp3）、服务器 Content-Type 配置及真实环境验证。
直接用 canPlayType() 在目标设备上跑一次判断，比查兼容表快得多，也准得多——表格过时、模拟器失真、文档没写清编解码器细节，只有真实环境能告诉你“这个 MP3 到底能不能播”。
用 canPlayType() 快速验证当前浏览器支持哪些格式
它不看文件后缀，只认 MIME 类型 + 编解码器组合。返回值只有三种："probably"（高置信度可用）、"maybe"（容器匹配但编码不确定）、""（空字符串，即不支持）。
常见误判点：
-
audio/mp4在 Safari 中大概率返回""，必须写成audio/mp4; codecs="aac"才可能得"probably" -
audio/mp3是错的写法，正确是audio/mpeg；写错就等于没声明，Safari 直接跳过该<source></source> - Firefox 对 VBR 编码的 MP3 可能卡住，即使
canPlayType('audio/mpeg')返回"probably"，实际播放也可能失败
为什么不能只在 Chrome DevTools 里测
DevTools 的 Device Mode 是模拟，不是仿真。它的编解码器列表和真实 iOS 设备、旧版 Android WebView 完全不同——比如：
立即学习“前端免费学习笔记（深入）”；
- iOS Safari 对
audio/ogg常静默跳过，DevTools 却显示支持 - 某些企业内网 Android 设备禁用 MP3 解码，但模拟器里一切正常
- 本地双击 HTML 走
file://协议时，Chrome/Firefox 会屏蔽音频加载，控制台甚至不报错
必须真机访问：用 python3 -m http.server 8000 启服务，再用手机浏览器打开 http://[本机IP]:8000/test.html。
配合 Network 面板确认服务器响应头是否正确
200 状态码 ≠ 音频能播。关键看响应头里的 Content-Type：
- MP3 文件必须返回
Content-Type: audio/mpeg，不是text/plain或空着 - Apache 用户需加
AddType audio/mpeg .mp3到.htaccess - Nginx 用户需在
types块中补audio/mpeg mp3; - 本地开发时，若用 VS Code Live Server 插件，它默认不设正确 MIME，仍需换
http.server
写个最小可测 HTML 页面，带诊断逻辑
把下面代码存为 test-audio.html，用本地服务打开，就能看到每个格式的实际支持状态：
<audio id="test-audio">
<source src="test.mp3" type="audio/mpeg">
<source src="test.opus" type="audio/opus">
<source src="test.wav" type="audio/wav">
</audio>
<script>
const audio = document.getElementById('test-audio');
console.log('audio/mpeg:', audio.canPlayType('audio/mpeg'));
console.log('audio/opus:', audio.canPlayType('audio/opus'));
console.log('audio/wav:', audio.canPlayType('audio/wav'));
</script>
注意：三个 <source></source> 对应的文件不用真实存在，canPlayType() 只检测解码能力，不发起网络请求。但后续真要播，就得确保路径有效、服务器头正确、且用户已触发手势。
最常被忽略的是：你测出来的 "probably"，只代表“浏览器说它能解”，不代表“这个具体文件编码没问题”——WAV 若是 32-bit float 格式，iOS Safari 仍会静音；MP3 若含 ID3v2.4 标签，部分 Android WebView 会卡在 loading 状态。真兼容，永远得靠格式 + 采样率 + 编码三者一起控。
