MP3+OGG仍不稳因Safari对audio/ogg支持极差、企业内网禁MP3解码、Android WebView忽略OGG；应按兼容性排序：MP3→OPUS→WAV，且必须配准type属性与服务端Content-Type。
MP3 是目前兼容性最稳的底线选择，但仅靠它仍会在 Firefox 某些版本、Linux 发行版浏览器或企业内网环境中失败——这不是 bug，是解码器缺失或策略限制。
为什么 MP3 + OGG 组合还不够稳
MP3 + OGG 覆盖了绝大多数桌面场景，但 Safari（尤其是 iOS）对 audio/ogg 支持极不稳定：即使写了 type="audio/ogg"，浏览器也可能跳过该 <source></source>；实测中 audio/wav 在 Safari 上反而更可靠，尤其适合短提示音。另外，部分 Android WebView 或 Chromium 嵌入环境会忽略 OGG，却能解码 audio/opus（Chrome/Firefox 已原生支持，体积比 MP3 小 30%～50%）。
- 顺序很重要：
<source></source>按 DOM 顺序尝试，应把兼容性最广、解码最快（通常是 MP3）放第一位 -
audio/wav文件大、加载慢，仅作兜底，别放第一 -
audio/opus需服务端返回正确Content-Type: audio/opus，否则会被跳过
必须加 type 属性，且值要精确匹配 MIME 类型
不写 type，Safari 和部分旧版 Firefox 可能直接跳过该 <source></source>，哪怕文件本身能播。服务端没配好 MIME 类型时，浏览器根本不会尝试解码。
-
MP3对应type="audio/mpeg"（不是audio/mp3） -
OGG对应type="audio/ogg" -
WAV对应type="audio/wav" -
OPUS对应type="audio/opus"
开发时务必打开 Network 面板，确认音频请求返回 200，且 Response Headers 中有匹配的 Content-Type。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
本地开发时 file:// 协议下音频必然失败
Chrome、Edge、Firefox 在双击 HTML 打开（地址栏为 file:///）时，会拒绝加载所有媒体资源——这是安全限制，不是路径写错。
- 必须起本地 HTTP 服务：用
npx serve、python3 -m http.server或 VS Code Live Server 插件 -
autoplay、play()、甚至部分preload行为在file://下全不可测 - 移动端 Safari 更严：即使走 HTTP，没用户手势触发也禁止有声播放
格式只是起点，真正卡住的往往是服务端配置、协议限制和交互时机——比如你调了 audio.play() 却没 catch 错误，控制台静默失败，连哪一步断掉都看不到。
