HTML音频播放失败主因是浏览器格式限制、MIME校验及用户手势策略；需用<source>多格式兜底（MP3+OGG）、服务端正确配置Content-Type、禁用autoplay改手动触发、检查userActivation状态。
HTML页面音频播不出，90%不是代码写错，而是没绕过浏览器的格式限制、MIME校验和用户手势策略。单靠 <audio src="a.mp3"> 几乎必然在某个浏览器或设备上静默失败。
audio 标签必须用 <source> 多格式兜底
只写一个 src 属性，等于把播放权交给浏览器掷骰子：Firefox 可能跳过，iOS Safari 甚至不触发 canplay 事件，控制台也不报错，只是没声音。
- 必须至少提供两组
<source>：<source src="a.mp3" type="audio/mpeg">+<source src="a.ogg" type="audio/ogg"> -
type值不能写错：audio/mp3是无效值，必须是audio/mpeg（MP3）或audio/ogg（OGG Vorbis） - Ogg 文件要确认编码是 Vorbis（用
ffprobe a.ogg查），不是 Opus；WAV 不建议作 fallback，Chrome 对 IEEE Float 编码的 WAV 直接拒绝 - 顺序很重要：浏览器从上到下匹配第一个支持的
type，所以把兼容性最强的 MP3 放最前
服务器必须正确返回 MIME 类型
即使 <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 面板确认音频请求返回 200，且响应头
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在多数桌面浏览器可行；但muted必须是布尔属性（不写值才生效），且后续 JS 别改volume
用户激活状态丢失后怎么恢复播放
页面切到后台一段时间后，navigator.userActivation.hasBeenActive 会被重置，此时再调 play() 仍会抛 DOMException。这不是偶发错误，而是浏览器主动清零用户授权状态。
- 每次调
play()前先检查：if (navigator.userActivation?.hasBeenActive) { audio.play() } - 若失效，监听下一次用户交互（如
click、touchstart），并在回调里立即调play() - 避免在
canplay或loadeddata回调里直接play()，iOS 上这些事件上下文不被视为有效手势来源 - 移动端尤其注意：不要依赖
preload="auto"，iOS 会忽略，且耗流量；设为preload="metadata"更稳妥
