先检查 audio 标签是否被浏览器识别：执行 document.queryselectorall('audio').length，返回 0 说明解析失败；再验证格式能否播放：监听 loadedmetadata 后调用 play().catch() 捕获错误；最后实机测试自动播放策略，覆盖 ios safari、微信、国产浏览器等真实环境。
怎么快速验证 audio 标签是否被浏览器识别
很多“没声音”“控件不显示”问题，根源是浏览器压根没把 <audio></audio> 当成合法元素——尤其在旧版 IE 或某些 WebView 中，它会被当成未知 inline 元素直接丢弃或包裹进 <div>。
<p>打开 Chrome 或 Edge 的 DevTools，切到 Elements 面板，手动展开 DOM 树，确认 <code><audio></audio> 节点是否完整存在、未被自动闭合或替换。更直接的方法是执行：document.querySelectorAll('audio').length，返回 0 就说明解析失败。
常见诱因包括： 前有 BOM、空格或注释；页面运行在 <code>file:// 协议下（部分 API 如 play() 会静默禁用）；IE8–10 缺 html5shiv 且未手动声明 audio { display: block; }。
怎么测音频格式能否真正播放（不止是标签渲染）
标签能渲染 ≠ 音频能解码播放。Chrome 支持 MP3、WAV、AAC；Safari 强制要求 H.264/AAC 封装的 MP4 容器（即 .m4a）；Firefox 对 MP3 支持稳定，但对 AAC 有兼容性波动；Android WebView 行为高度依赖系统版本和厂商定制内核。
实操建议：
• 在 <audio></audio> 内提供至少两种格式，例如：
<source src="bg.mp3" type="audio/mpeg"><br><source src="bg.m4a" type="audio/mp4"></source></source>
• 不要只靠
canPlayType() 返回 "probably" 就认为能播——它只是推测，不是运行时验证。• 真正可靠的判断方式：监听
loadedmetadata 后调 play().catch(e => console.warn('play failed:', e))，观察是否抛 NotAllowedError 或 DecodeError。
怎么模拟真实用户环境测自动播放策略
autoplay 属性在现代环境基本失效，测试重点不是“它写没写”，而是“它在什么条件下能绕过拦截”。桌面 Chrome/Firefox/Safari 要求：HTTPS + 用户已触发可信事件（click、touchstart、keydown）+ muted（有声播放必须等交互后）；iOS Safari 和微信 WebView 更严：即使 muted，首次 play() 也必须由 touchstart 触发，且每个 <audio></audio> 实例需单独预激活。
测试时务必覆盖：
• 是否监听了 loadedmetadata 再调 play()（避免元数据未就绪导致失败）
• 是否在用户点击后才调用，而非 DOMContentLoaded 或 setTimeout
• 多个音频元素是否分别调用了 play().then(() => pause()) 预激活
• 微信环境是否等待 WeixinJSBridgeReady 事件
为什么真机测试不能跳过
桌面浏览器 DevTools 的“设备模拟”只能骗过 UA 和 viewport，骗不过底层媒体策略。iOS 的 WKWebView 对音频上下文校验极严：手势时间戳、事件冒泡路径、页面焦点状态全参与判定；安卓厂商 WebView 可能禁用 MSE、阉割 WebAudio、或强制后台音频暂停；微信 iOS WebView 甚至会忽略 muted 属性本身。
必须实测的组合包括：
• iPhone Safari（iOS 16/17/18）
• 微信内置浏览器（iOS + Android 最新稳定版）
• 华为/小米/OPPO 自带浏览器（注意它们常基于 Chromium 但内核版本滞后）
• Chrome for Android（非模拟器，真机触控）
最容易被忽略的是：同一台手机上，微信里打不开的音频，在自带浏览器里可能正常——这不是代码问题，是容器策略差异。别信“测了 Chrome 就等于测了所有”。
