应使用 canPlayType() 探测并按需 fallback：若返回空字符串则切换 MP3，否则加载 WebM；必须调用 el.load() 重载资源，且 MP3 需预生成、符合编码规范。
audio 标签加载 WebM/Opus 时静音或报错
直接用 <audio src="tts.webm"></audio> 在 Safari 旧版本、部分安卓 WebView 或 Electron 旧内核里会失败，表现是：控件显示但点不动、控制台抛 DOMException: The element has no supported sources、或无声播放。这不是文件损坏，而是浏览器根本不识别这个封装+编码组合。
解决思路不是“统一转格式”，而是运行时探测 + 按需 fallback：
- 先用
HTMLMediaElement.canPlayType()主动查当前浏览器对audio/webm; codecs="opus"的支持等级（返回"probably"/"maybe"/""） - 若返回空字符串，说明不支持，立刻切换到备用路径（比如提前准备好的 MP3）
- 不要依赖
error事件——它可能不触发，或触发太晚（用户已点播放）
如何写一个可靠的格式探测 + 替换逻辑
核心是把探测和替换收进一个函数，避免重复判断。示例代码（ES6）：
function loadAudio(el, webmSrc, mp3Src) {
const canPlayWebM = el.canPlayType('audio/webm; codecs="opus"');
if (canPlayWebM === 'probably' || canPlayWebM === 'maybe') {
el.src = webmSrc;
} else {
el.src = mp3Src;
}
el.load(); // 强制重新加载资源
}
注意：canPlayType() 返回值不是布尔值，必须严格比对字符串；el.load() 不可省略，否则改 src 后不会自动重载元数据。
立即学习“前端免费学习笔记（深入）”；
MP3 备用方案的生成与维护成本
IndexTTS2 输出 WebM 是高效选择，但加 MP3 fallback 会带来额外负担：
- 不能靠前端 JS 实时转码（无 Opus→MP3 的纯浏览器解码器）
- 必须在服务端预生成 MP3，或用 FFmpeg 封装工具类（如你知识库提到的 Java 封装）批量处理
- MP3 文件体积通常是 WebM 的 3–5 倍，CDN 流量和加载延迟会上升
- 若只针对 Safari 14+ 用户，其实可完全不加 fallback——iOS/macOS 14 已覆盖 98%+ 设备
audio.js 等封装库是否能绕过兼容问题
不能。像 audio.js 这类库只是对原生 <audio></audio> 的语法糖封装，底层仍走相同加载路径。它无法让 Safari 8 突然理解 Opus 编码，也不能在不支持的环境里注入解码器。
真正起作用的只有两件事：一是用 canPlayType() 提前规避，二是确保 fallback 资源真实可用（路径正确、HTTP 头没禁跨域、CORS 配置允许）。最容易被忽略的是：MP3 文件本身若用 LAME 非标准参数导出（比如 VBR + 不带 ID3v2），某些旧 Android 内核也会拒绝加载——务必用 ffprobe 检查编码细节。
