必须同时提供MP3和OGG双格式并显式声明type，因浏览器需预判解码能力：MP3（type="audio/mpeg"）覆盖全平台，OGG（type="audio/ogg"）补足Firefox等；单靠src属性无法触发格式预判，易致Safari静默跳过、Chrome报无源错误。
MP3 和 OGG 必须同时提供，只放一种格式等于主动放弃部分用户——Firefox 不认 MP3，Safari 早期版本不认 OGG，Chrome 虽然两者都支持，但遇到 MIME 类型缺失或服务器配置错误时仍会静默失败。
为什么单靠 src 属性不够用？
直接写 <audio src="song.mp3"></audio> 看似简洁，但浏览器无法提前判断该文件是否可解码，尤其当服务器未正确返回 Content-Type: audio/mpeg 时，Chrome 可能加载成功却报 DOMException: The element has no supported sources；而 Safari 可能干脆不触发 canplay 事件。
改用 <source></source> 显式声明 type 后，浏览器可在加载前做格式预判，跳过不支持的源，避免卡死在第一个失败项上。
-
<source src="song.mp3" type="audio/mpeg"></source>—— MP3 是底线，覆盖所有主流桌面/移动浏览器 -
<source src="song.ogg" type="audio/ogg"></source>—— 补足 Firefox、旧版 Chrome 和部分 Linux 浏览器 -
<source src="song.wav" type="audio/wav"></source>—— 仅作兜底，文件体积大、加载慢，不建议作为主力
如何验证浏览器实际加载了哪个格式？
别光看页面有没有控件，要确认音频真被解码了。打开 DevTools → Network 标签页，播放时观察哪个 .mp3 或 .ogg 请求返回了 200，并检查响应头里的 Content-Type 是否匹配 <source></source> 中写的 type 值。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
更直接的办法是监听 loadedmetadata 事件后读取 audio.src：
const audio = document.getElementById('myAudio');
audio.addEventListener('loadedmetadata', () => {
console.log('实际加载地址：', audio.src); // 会显示最终选中的那个 source 的完整 URL
});
如果始终为空或报错，说明所有 <source></source> 都被跳过，大概率是路径错、404、MIME 错配或 CORS 阻断。
服务器端 MIME 配置不能省
哪怕 HTML 写对了 type，如果 Web 服务器没把 .ogg 文件响应为 audio/ogg，Firefox 就会拒绝解码。Nginx 和 Apache 默认都不认识 .ogg，必须手动加：
- Nginx：
types { audio/ogg ogg oga; }放在http或server块里 - Apache：
AddType audio/ogg .ogg .oga加到.htaccess或虚拟主机配置 - Vercel / Netlify：需在
_headers或netlify.toml中显式设置
本地开发用 python3 -m http.server 会默认返回 application/octet-stream，此时即使加了 type 也无效——务必换用支持 MIME 推断的本地服务（如 live-server）或部署后再测。
最常被忽略的一点：音频文件本身编码是否合规。用 ffmpeg -i song.mp3 -vcodec copy -acodec copy output.mp3 重新封装一次，能绕过某些老旧 MP3 文件头损坏导致的 Safari 解码失败问题。
