现代浏览器强制 audio 静默播放需设 muted 属性，volume="0" 无效；须先 muted autoplay 加载，用户交互后再解除静音；ios/微信需每个 audio 单独预激活（play().then(pause())），且路径、格式、服务环境须合规。
现代浏览器不允许 Audio 标签在无用户交互前提下“有声后台播放”，所谓“静默播放”唯一合规路径是显式设置 muted 属性——它不是权宜之计，而是策略准入的硬性开关。
为什么 autoplay + volume="0" 无效
浏览器只认 muted 布尔属性，不解析 volume 数值。哪怕你写 volume="0" 或用 JS 设置 audio.volume = 0，只要没挂 muted，就仍被视为“有声媒体”，触发自动播放拦截。
-
autoplay单独存在 ≈ 被忽略（Chrome、Safari、Firefox 统一行为） -
volume="0"不等于muted：前者只是音量调零，后者是向浏览器声明“此媒体无声音输出” - 即使加了
muted，iOS Safari 和微信 WebView 仍要求首次播放必须由click或touchstart触发
如何让背景音乐真正“无声启动”并后续可控
目标是：页面加载后立即静音播放（满足 autoplay），同时保留后续取消静音、调节音量、切换音频的能力。关键在于分两步走：初始化静音激活 + 用户交互后解除静音。
- HTML 中必须写
<audio muted autoplay loop><source src="/media/bgm.mp3" type="audio/mpeg"></source></audio> - 监听
loadedmetadata而非canplay或load：确保元数据（时长、编码）已就绪，避免play()因格式未识别而失败 - 用户首次点击后，再执行
audio.muted = false并audio.play()—— 此时不再被拦截，因为上下文已激活 - 不要在
DOMContentLoaded里调play()，哪怕加了muted，iOS 仍可能拒绝（尤其微信 WebView）
iOS 和微信 WebView 的预激活陷阱
多个 audio 元素不能共用一次用户手势。iOS 对每个实例单独校验“是否被用户手势激活过”，漏掉任何一个，后续调用 play() 都会抛 NotAllowedError。
- 对每个需后续控制的
audio元素，在首次click事件中分别执行一次play().then(() => pause()) - 这个“播放-暂停”操作必须发生在用户手势回调内，不能用
setTimeout延迟，否则 iOS 认为脱离上下文 - 微信 WebView 还要等
WeixinJSBridgeReady事件，否则play()直接静默失败，无报错 -
preload="metadata"是安全选择；preload="auto"在 iOS 上常被忽略，且可能触发无意义带宽消耗
路径、格式与本地调试常见断点
90% 的“没声音”问题其实和自动播放策略无关，而是资源根本没加载成功。
- 检查控制台是否有
GET http:///xxx.mp3 404 (Not Found)：路径以当前 HTML 文件为基准，推荐用根相对路径src="/media/bgm.mp3" - 避免双击打开 HTML 文件（
file:///协议）：Chrome 和 Safari 会禁掉音频加载，务必用python3 -m http.server启本地服务 - 单一
src易兼容失败：MP3 在 Firefox 某些编码下不支持，Ogg 在 Safari 旧版失效，务必用<source></source>提供回退：<source src="bgm.mp3" type="audio/mpeg"><source src="bgm.ogg" type="audio/ogg"></source></source> - 漏写
controls属性不会导致播放失败，但会让开发者误以为“控件灰了=没加载”，其实是默认隐藏 UI
最易被跳过的细节：每个 audio 实例都要独立预激活，不是“播一个，全解封”。iOS 的校验粒度精确到 DOM 节点，不是页面级。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
