根本不存在“兼容提示”,浏览器对不支持的音频格式静默失败;必须用显式声明多格式、配对正确mime类型、依赖用户手势触发播放。

根本不存在“兼容提示”——浏览器从不弹窗告诉你“这个音频格式不支持”。所谓“提示”,其实是静默失败:没声音、canplay不触发、duration为NaN、控制台空空如也。问题出在 fallback 没写对,不是缺个提示。
audio 标签只写一个 src 就等于放弃兼容
只写 <audio src="a.mp3"></audio>,Firefox 会跳过,Safari 可能播一半卡住,iOS Safari 直接不加载。浏览器不会报错,只是把请求当普通文本扔掉。
- 必须用
<source></source>显式声明多格式,至少两组:<source src="a.mp3" type="audio/mpeg"></source>+<source src="a.ogg" type="audio/ogg"></source> -
type值不能写错:audio/mp3是无效的,必须是audio/mpeg;audio/ogg不能写成audio/vorbis - 顺序很重要:把兼容性最广的放最前(MP3),WAV 或 OPUS 放最后——它们体积大或支持窄,仅作兜底
服务器 MIME 类型配错,audio 就是死标签
即使 <source></source> 写得再全,如果响应头里 Content-Type 是 text/plain 或空着,浏览器连解码器都不会调用。
- Apache 用户,在
.htaccess或虚拟主机配置加:AddType audio/mpeg .mp3、AddType audio/ogg .ogg - Nginx 用户,在
types块里补:audio/mpeg mp3;、audio/ogg ogg; - 本地开发别双击 HTML 文件——
file://协议下 Chrome/Firefox 会屏蔽音频加载,改用python3 -m http.server 8000 - 检查 Network 面板,确认每个音频请求的响应头
Content-Type精确匹配后缀和编码
autoplay 失效不是 bug,是策略强制拦截
写了 autoplay 还没声音?不是 JS 错了,是浏览器在等用户“动手”。现代浏览器(含微信 iOS)要求首次播放必须由用户手势触发,否则 play() 返回被 reject 的 Promise,控制台报 The play() request was interrupted。
- 删掉
autoplay属性,改用按钮点击触发:document.querySelector('button').addEventListener('click', () => audio.play().catch(e => {})) - 不要在
DOMContentLoaded或window.onload里调play(),100% 失败 - iOS Safari 更严格:元素必须在视口内、未被
display: none或opacity: 0遮挡,否则即使点过也静音 - 想静音自动播?
muted+autoplay在多数桌面浏览器可行;想有声自动播?只能等用户第一次交互后再调一次play()
最容易被忽略的是:你永远无法靠 JS 动态判断“哪个格式能播”,canPlayType() 返回 "probably" 不等于真能播。真正可靠的 fallback,只有静态写死的 <source></source> 顺序 + 正确 MIME + 用户手势触发这三者同时成立。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











