audio标签兼容性取决于顺序、type精度和服务端响应头三者严丝合缝；顺序错误则浏览器立即加载首个可识别源并停止后续尝试，safari不认audio/ogg而chrome优先opus，故推荐opus→m4a→mp3顺序，且type须精确到编码、服务端content-type必须完全匹配。
audio 标签本身不决定兼容性，真正起作用的是 <source></source> 的顺序、type 声明精度和服务端响应头三者是否严丝合缝。只写一个 src 或漏掉 type，Safari 和 iOS 就大概率静默失败。
为什么顺序错了就全白搭
浏览器按 DOM 中 <source></source> 出现顺序逐个调用 Audio.canPlayType()，只要返回 "probably" 或 "maybe" 就立刻加载并停止后续尝试。Safari 17.5 完全不认 audio/ogg，哪怕你写了 <source src="a.opus" type="audio/ogg; codecs=opus"></source>，它直接跳过；Chrome 却优先识别 Opus，放最前才能省带宽。
- 推荐 fallback 顺序：
<source src="a.opus" type="audio/ogg; codecs=opus"></source>→<source src="a.m4a" type="audio/mp4; codecs=aac"></source>→<source src="a.mp3" type="audio/mpeg"></source> - 别把
.wav放第一位——16-bit PCM 文件动辄几 MB，Firefox 虽能解码，但用户得等完整下载才出声 - 删掉没声明
type的<source></source>：浏览器可能跳过 MIME 检查直接试播，结果报MEDIA_ERR_DECODE却找不到原因
type属性不是可选项，而是解码开关
只写 type="audio/ogg" 不够，必须精确到编码：type="audio/ogg; codecs=opus"。Chrome 对 audio/ogg 返回 "probably" 仅当后缀是 .opus 且内部确实是 Opus 编码；.ogg 封装 FLAC？它直接返回空字符串，等于宣告不支持。
- 验证方法：打开控制台执行
Audio.canPlayType('audio/ogg; codecs="opus"')，返回"probably"才算稳 -
.m4a文件必须含 AAC-LC（不是 HE-AAC、不是 ALAC），用ffprobe file.m4a看codec_name是否为aac - 服务器返回的
Content-Type必须和type值完全一致，比如audio/ogg; codecs=opus对应响应头Content-Type: audio/ogg，不能是application/octet-stream
服务端没配对，前端写成诗也没用
90% 的“静音”“卡 loading”“controls 拖不动”，问题不在 HTML，而在 Nginx/Apache 没开 Range 请求、没设对 MIME、没配 CORS。
- Nginx 需显式加：
add_type audio/ogg .opus;、add_type audio/mp4 .m4a;、add_type audio/mpeg .mp3; - 跨域音频必须响应头含
Access-Control-Allow-Origin: *，否则 Safari 直接拒绝解码，连错误都不抛 - 本地开发用
file://协议时，Chrome 会禁用自动播放，必须起本地服务器（如python3 -m http.server）
最容易被忽略的是服务端配置——前端能写的都写了，但 Content-Type 错一位、Range 头没开、CORS 缺失，音频照样不响。调试时先看 Network 面板里音频请求的响应头，别急着改 HTML。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
