canPlayType()返回空字符串不是bug，而是浏览器明确声明不支持该MIME+编解码器组合，如audio/mp4未带codecs="aac"参数时Safari直接返回""。
不兼容是常态，兼容是精心配置的结果。只写 <audio src="a.mp3"></audio>，在 iOS Safari 或旧版 Firefox 上基本等于静音失败。
为什么 canPlayType() 返回空字符串不是 bug
canPlayType() 是唯一可信的运行时判断方式，但它返回空字符串（""）根本不是报错——而是浏览器明确告诉你：“这个 MIME + 编解码器组合，我连解码器都不会调用”。常见触发场景：
-
audio/mp4没带codecs参数 → Safari 直接返回""，哪怕文件后缀是.m4a -
audio/ogg实际封装的是 FLAC → Chrome 拒绝识别，canPlayType('audio/ogg')返回""，但ffprobe a.ogg会显示codec_name=flac -
audio/wav用了 IEEE 754 浮点编码 → 所有主流浏览器都返回""，必须确认是pcm_s16le（16-bit PCM little-endian）
验证方法：在控制台执行 Audio.canPlayType('audio/ogg; codecs="opus"')，只有返回 "probably" 才代表高置信度可用。
MP3、Opus、WAV 在各浏览器的实际支持边界
不是“支持 MP3”，而是“支持特定编码参数的 MP3”；不同浏览器对同一后缀的容忍度差异极大：
立即学习“前端免费学习笔记（深入）”；
-
.mp3：仅限 MPEG-1 Layer III，采样率 ≤48 kHz；HE-AAC、VBR 混合码率在 Firefox 中可能卡住、Safari 中静音 -
.opus：Chrome 126 / Firefox 127 原生支持，体积比 MP3 小 30%～50%，但 Safari 17.5 仍完全不识别audio/opus -
.wav：只认 16-bit PCM（CD 格式），μ-law、a-law、IEEE 浮点全被拒；iOS Safari 对短 WAV 提示音兼容性反而优于 MP3
别信“MP3 全平台通吃”——企业内网环境常因版权策略禁用 MP3 解码器，只放行 WAV 或 OPUS。
source 标签顺序和 type 属性怎么写才不白费
浏览器按 DOM 顺序逐个尝试 <source></source>，遇到第一个 canPlayType() 非空就停。顺序错了，fallback 就失效：
- 把
<source src="a.ogg" type="audio/ogg"></source>放第一位？Safari 直接跳过，不试第二个 - 写
type="audio/mp3"（错误 MIME）→ 浏览器当无效源忽略，不加载也不报错 - 漏写
type属性 → iOS Safari 静默跳过，duration为NaN，控件不响应 - 推荐顺序：
<source src="a.opus" type="audio/opus"></source>→<source src="a.m4a" type="audio/mp4; codecs=" aac></source>→<source src="a.mp3" type="audio/mpeg"></source>
注意：audio/mp4; codecs="aac" 中的双引号必须是英文直引号，且不能省略；写成 codecs=aac（无引号）在 Safari 中大概率失效。
服务端配置比前端代码更致命
前端写对了，服务端没配好，照样 404、静音、进度条无法拖动：
- 响应头
Content-Type必须精确匹配：.mp3 文件返回text/plain，Chrome 直接扔掉，连解码器都不唤起 - 跨域音频必须开 CORS：
Access-Control-Allow-Origin: *，否则 Safari 拒绝解码（不是报 CORS 错，是静默失败） - 必须支持
Range请求头：否则preload="metadata"读不到时长，controls进度条灰掉、无法拖动 - Nginx 示例配置：
types { audio/mpeg mp3; audio/ogg ogg; audio/opus opus; }
本地开发别双击 HTML 打开——file:// 协议下 Chrome/Firefox 会屏蔽音频加载，务必用 python3 -m http.server 8000 启服务。
