真正能“最大化兼容”的是用<source>构建可退阶加载链，而非单选格式；需按opus→m4a→mp3→wav顺序精确声明type与codecs，并确保服务端MIME、CORS、Range配置正确。
只打包一种格式，无论 MP3、WAV 还是 OGG，都必然在至少一个主流浏览器里静音或报错。真正能“最大化兼容”的不是选对单个格式，而是用 <source> 构建可退阶的加载链，且每个环节都经浏览器解码器验证。
为什么不能只靠 MP3 + OGG
MP3 + OGG 看似覆盖桌面端，但漏掉两个硬伤场景：
- iOS Safari 对
audio/ogg声明常跳过请求，哪怕文件真实存在；实测中audio/wav（16-bit PCM）反而更稳，尤其短提示音 - 某些企业内网禁用 MP3 解码（版权策略），只允许
audio/opus或audio/wav；audio/opus在 Chrome/Firefox 中体积比 MP3 小 30%～50%，且已稳定支持 -
audio/mp4（即 .m4a）是 Safari/iOS 原生首选，但必须确认内部编码是 AAC-LC（不是 HE-AAC 或 ALAC），否则canPlayType()返回空字符串
source 顺序和 type 声明必须精确到 codecs
浏览器按 DOM 顺序逐个调用 canPlayType()，第一个返回 "probably" 的就加载，后续全部跳过。顺序错了，高兼容格式根本没机会执行。
- 推荐 fallback 顺序：
<source src="a.opus" type="audio/ogg; codecs=opus">→<source src="a.m4a" type="audio/mp4; codecs=aac">→<source src="a.mp3" type="audio/mpeg">→<source src="a.wav" type="audio/wav"> - MP3 必须写
type="audio/mpeg"，不是audio/mp3；WAV 必须写type="audio/wav"，Safari 不认audio/x-wav - 验证是否真支持：控制台运行
Audio.canPlayType('audio/ogg; codecs="opus"')，返回"probably"才算过关
服务端配置比前端写法更容易被忽略
前端写得再规范，服务端 MIME 类型、Range 请求、CORS 缺一不可。Nginx 示例配置：
立即学习“前端免费学习笔记（深入）”；
add_type audio/ogg .opus;
add_type audio/mp4 .m4a;
add_type audio/mpeg .mp3;
add_type audio/wav .wav;
<p>location ~ .(opus|m4a|mp3|wav)$ {
add_header Access-Control-Allow-Origin *;
add_header Accept-Ranges bytes;
}- 响应头
Content-Type必须和<source type>完全一致，比如audio/ogg; codecs=opus对应Content-Type: audio/ogg，返回application/octet-stream就直接失败 - 不支持
Accept-Ranges的服务器会导致 Safari 卡在 loading、拖动进度条无效 - GitHub Pages 默认不加 CORS 响应头，跨域音频请求会被静默拦截，连 error 事件都不触发
JS 播放必须捕获三类错误并区分处理
用户点击后调用 play() 不等于一定能响，必须显式处理拒绝路径：
audio.play().catch(e => { if (e.name === 'NotAllowedError') { /* 静音重试或引导用户点击 */ } })- 监听
error事件：当所有<source>都加载失败时，audio.error?.code为4（MEDIA_ERR_SRC_NOT_SUPPORTED） - 别依赖
canplay：它只表示元数据就绪，音频体可能还没下载完；canplaythrough更可靠但延迟高，短音频建议用loadeddata
最常被绕过的点是：本地开发用 file:// 协议时，Chrome 直接禁用 play()，必须起本地服务（如 python3 -m http.server）；而 iOS Safari 要求首次播放前页面已获得用户手势授权——哪怕只是点过空白区域。
