音频加载失败主因是格式兜底、mime声明或加载时机错误：必须用显式声明audio/mpeg和audio/ogg双源，type不可写错；服务器需配对content-type；play()须由用户手势触发。
音频加载失败，90% 不是代码写错，而是格式兜底、MIME 声明或加载时机没对上。
audio 标签只写 src 属性为什么在 Safari 和 Firefox 里静默失败
浏览器不靠文件后缀猜格式，它只认 type 属性。省略 type 时，Chrome 可能碰巧加载 MP3，但 Safari（尤其 iOS）会直接跳过该 <source></source>，连 canplay 都不触发，控制台也无报错——就是“无声失败”。
- 必须用
<source></source>显式声明格式：<source src="bg.mp3" type="audio/mpeg"></source>（不是audio/mp3） - Firefox/Linux 常依赖 OGG，补上：
<source src="bg.ogg" type="audio/ogg"></source>，编码必须是 Vorbis（可用ffprobe bg.ogg确认输出含Audio: vorbis） - 别加
.wavfallback：体积大、Chrome 对 IEEE Float 编码的 WAV 直接拒绝 - 多个
<source></source>按顺序匹配，第一个type被支持的就用，所以 MP3 放最前
Network 面板看到 200 但 audio 还是不播，检查 Content-Type 响应头
即使路径正确、格式合法，如果服务器返回的响应头里 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 - 打开 DevTools → Network → 点音频请求 → 查看 Response Headers 里的
Content-Type是否匹配后缀和编码
autoplay muted 写了还是没声音，问题出在用户手势缺失
现代浏览器（含微信 iOS）强制要求首次播放必须由用户真实交互触发，否则 play() 返回被 reject 的 Promise，控制台报 The play() request was interrupted。这不是 bug，是策略。
- 删掉
autoplay属性，改用按钮点击触发：document.querySelector('button').addEventListener('click', () => audio.play().catch(e => {})) - iOS Safari 更严：元素必须在视口内、未被
display: none或opacity: 0遮挡，否则点过也无效 - 不要在
DOMContentLoaded或load回调里调play()，100% 失败 - 想“静音启动”？
autoplay muted组合在桌面端基本可行，但 iOS 仍需先有一次用户点击（哪怕点空白处）才能解锁后续所有play()
preload="auto" 让页面卡顿、移动端首屏变慢，该怎么设
preload="auto" 在 2026 年已基本弃用：Lighthouse 标为“性能风险”，Safari 实际忽略，且对 >2MB 的音频会阻塞首屏渲染、浪费流量。
- 小音频（如提示音、BGM 片段）→
preload="metadata"：秒出时长、可拖拽，不加载音频数据 - 大音频（播客、课程录音）→
preload="none"：等用户明确点击再加载，更省流量、更可控 - 背景音乐类自动播放场景，可省略
controls，用 JS 监听click后调play()，避免 UI 干扰 - 别信
canPlayType()返回"probably"就一定能播——它只是推测，不如静态<source></source>fallback 可靠
真正容易被忽略的是：服务器 MIME 配置和用户手势授权是两个独立关卡，缺一不可。前者决定音频能不能“加载进来”，后者决定能不能“播得出来”。两者都得验，不能只查一个。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
