MP3+OGG是覆盖99%场景的最小成本兼容方案：MP3放首位（type="audio/mpeg"），OGG次之（type="audio/ogg"），必须写type且不可省略，顺序错误或缺失type将导致浏览器跳过或报错。
MP3 是目前浏览器兼容性最广的 HTML 音频格式。
它在 Chrome、Safari、Edge、Opera 和 IE9+ 中全部原生支持，Firefox 是唯一主流例外（不支持 MP3），但这个缺口完全可以通过多格式兜底轻松绕过——不需要为兼容性妥协音质或体积。
audio 标签中怎么写多格式才真正生效？
关键不在“写了几个 source”，而在顺序 + type 属性 + 浏览器加载策略：
- 浏览器按
source出现顺序尝试加载，遇到第一个能解码的就停，后续忽略 - 必须写
type属性，否则浏览器无法预判是否支持，可能跳过该源直接报错 -
MP3放第一位，OGG放第二位，是经过验证的最小成本兼容方案
<audio controls> <source src="sound.mp3" type="audio/mpeg"> <source src="sound.ogg" type="audio/ogg"> 您的浏览器不支持音频播放。 </audio>
注意：不要省略 type；不要把 OGG 放前面（Firefox 虽支持，但其他浏览器会因不识别而跳过整个 audio）；不要指望只靠文件后缀判断——浏览器看的是实际编码，不是扩展名。
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
为什么不用 WAV 或 AAC？
-
WAV：音质无损，但体积巨大（1 分钟 ≈ 10MB），且 Chrome、Safari、IE 均不支持。仅 Firefox 和部分旧版 Opera 可播，实用性极低 -
AAC：虽被 Safari 和 iOS 原生偏好，但作为独立文件（如.aac）在 Chrome 和 Firefox 中无法直接播放；它主要用在MP4容器里，不适合作为audio的独立源 -
OPUS：压缩率高、延迟低，但仅在 WebM 容器中有效（audio/webm; codecs=opus），Chrome/Firefox 支持好，Safari 直到 2025 年才开始有限支持，移动端 WebView 兼容混乱
所以日常开发中，MP3 + OGG 组合覆盖 99% 场景，其余格式只在特定需求（如录音上传、WebRTC 传输）中出现。
编码参数比格式本身更容易翻车
即使选了 MP3，以下参数问题也会导致播放失败或卡顿：
- 比特率超过 320kbps：部分低端安卓设备解码吃力，出现爆音或静音
- 采样率不是 44.1kHz 或 48kHz：iOS Safari 对非标采样率容忍度低，可能静音播放
- 使用了 VBR（可变比特率）：某些老版本 Android WebView 解析失败，建议统一用 CBR（恒定比特率）
- ID3 标签版本过高（如 ID3v2.4）：极少数嵌入式浏览器解析异常，回退到 ID3v2.3 更稳妥
用 ffmpeg 统一转码是最稳做法：
ffmpeg -i input.mp3 -ar 44100 -ac 2 -b:a 128k -c:a libmp3lame -id3v2_version 3 output.mp3
真实项目里最容易被忽略的，不是“该用什么格式”，而是没验证最终生成文件的编码信息是否匹配声明的 type。很多构建流程自动重命名或 CDN 自动转码后，.mp3 文件实际变成了 AAC 编码，但 type="audio/mpeg" 还挂着——这时浏览器拒绝播放，控制台只报一个模糊的 DOMException: The element has no supported sources，排查起来非常耗时。
