audio标签仅是容器，兼容性由浏览器解码器决定；mp3+m4a为最稳fallback组合，需配合正确mime类型与canplaytype检测。
audio 标签本身不决定兼容性，浏览器解码器才管用
HTML 的 <audio></audio> 标签只是个容器，它不自带解码能力。真正决定“能不能播”的，是用户设备上浏览器内嵌的音频解码器——而不同浏览器、甚至同一浏览器在不同操作系统或发行版里，启用的解码器都可能不同。
比如 Firefox 在某些 Linux 发行版中默认禁用 MP3 解码器（因专利授权问题），哪怕你写了 <source src="a.mp3" type="audio/mpeg"></source>，它也会跳过；Safari 则压根不认 audio/ogg，无论你的 .ogg 文件多标准，控制台只会静默失败，连错误都不报。
- 不要依赖文件后缀判断支持情况 ——
.m4a文件若封装的是 ALAC 而非 AAC，Safari 同样无法播放 - 用
canPlayType()做运行时检测比 UA 判断更可靠：new Audio().canPlayType('audio/mp4; codecs="aac"')返回"probably"才算真支持 - Chrome 和 Edge 对
audio/webm（Opus）支持良好，但 Safari 17 仍不支持 —— 这不是 bug，是 Apple 明确没实现
MP3 + M4A 是目前最稳的 fallback 组合
单靠一种格式永远不够。2026 年实测下来，audio/mpeg（MP3）和 audio/mp4（M4A/AAC）覆盖了 99% 以上的有效流量，且无明显兼容断层。
WAV 虽然“全支持”，但体积大、无压缩，一段 20 秒语音常超 3MB；OGG 在 Safari 和旧版 iOS WebView 中直接不可用，等于主动放弃移动端近半用户。
-
<source src="speech.mp3" type="audio/mpeg"></source>放第一位 —— Chrome/Firefox/Edge 默认走这里 -
<source src="speech.m4a" type="audio/mp4"></source>紧跟其后 —— Safari/iOS 必须靠它，且需确认编码确实是 AAC（用ffprobe speech.m4a查codec_name） - 别把
.wav放最后当保底 —— 它容易因 MIME 错误或路径问题被跳过，导致降级提示误触发
服务器 MIME 类型配错，比代码写错还致命
即使 <source></source> 写得完全正确，只要服务器返回的 Content-Type 不匹配 type 属性，浏览器就会直接忽略该源 —— 控制台通常只报 DOMException: The element has no supported sources，根本看不出是服务端问题。
- Nginx 需显式加 types 配置：
types { audio/mpeg mp3; audio/mp4 m4a; audio/ogg ogg; } - Apache 用
AddType audio/mpeg .mp3，不能只靠后缀自动推断 - 本地开发用 Python 的
python -m http.server默认不设 MIME，必须换serve或live-server等带正确头的工具
autoplay 失败从来不是 audio 标签的锅
现代浏览器（包括 Chrome 120+、Safari 17+、Firefox 125+）全部强制执行自动播放策略：未获用户手势（click/touchstart）前，autoplay 要么静音，要么被拒绝。这不是 bug，是规范行为。
常见误操作是给 <audio></audio> 加 muted autoplay 就以为万事大吉 —— 但 iOS Safari 会直接忽略 muted，仍要求首次交互后才能调 play()。
- 正确做法：用按钮触发播放，而非 onload 自动调用
play() - JavaScript 中捕获首次交互后调用：
audio.play().catch(e => console.warn("play() rejected:", e)) - 避免在页面加载完成事件里反复重试
play()—— 浏览器会将后续调用视为无效，且可能抛出NotAllowedError
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
