浏览器支持 Audio 构造函数的可靠检测方式是 typeof Audio !== 'undefined' && typeof Audio === 'function'，再通过 try { new Audio() } catch {} 验证；旧版 IE 和部分 Android 4.x WebView 不支持，会抛出 ReferenceError。
如何判断浏览器是否支持 Audio 构造函数
几乎所有现代浏览器都支持 Audio 构造函数，但旧版 IE（≤11）完全不支持，部分 Android 4.x WebView 也会抛出 ReferenceError。直接调用 new Audio() 可能导致脚本中断，必须先检测。
推荐写法是用 typeof Audio !== 'undefined'，而不是 'Audio' in window——后者在某些沙箱环境（如微信内置浏览器早期版本）会返回 true，但实际调用仍报错。
-
typeof Audio是最轻量、最可靠的运行时存在性检查 - 若为
'function'，再尝试实例化一个空对象：try { new Audio() } catch(e) { /* 不支持 */ } - 注意：Safari 在无用户手势（如 click）上下文中创建
Audio实例不会报错，但后续play()会被静音策略拦截——这属于行为兼容，不是构造函数兼容
如何检测特定音频格式能否被解码
Audio 对象存在 ≠ 能播放某类文件。canPlayType() 是唯一标准接口，但返回值语义模糊：'probably'、'maybe'、''（空字符串），且各浏览器实现差异大。
常见误判点：传入 'audio/mp3' 在 Chrome 中返回 'probably'，但在 Firefox 中返回 ''（它只认 'audio/mpeg'）；'audio/wav' 在 Safari 中基本不可靠。
立即学习“前端免费学习笔记（深入）”；
- 务必使用 MIME 类型全称：
audio/mpeg、audio/ogg、audio/wav、audio/flac - 不要依赖
'probably'就认为一定能播——它只表示“有解码器且类型匹配”，不保证文件头合法或资源可加载 - 真实可用的检测方式是预加载 +
oncanplaythrough或onerror回调，但代价是网络请求
如何应对 iOS Safari 的自动播放限制
iOS Safari（包括所有 WKWebView）强制要求音频必须由用户手势触发才能播放，且首次 play() 必须在事件回调内同步调用，不能异步（如 setTimeout、Promise.then）。
典型错误：点击按钮后发请求、等音频 URL 返回再 new Audio(url).play()——这在 iOS 上必然失败，报错 NotAllowedError: The request is not allowed by the user agent or the platform in the current context。
- 解决方案：在用户点击瞬间就创建并调用
play()（哪怕传空src），建立播放上下文；之后再动态设置src并调用play() - 示例：
const a = new Audio(); a.play().catch(() => {}); // 建立上下文；a.src = 'x.mp3'; a.play(); - 注意：iOS 15+ 允许
play()返回 Promise，但低版本仍需用回调风格处理拒绝
如何识别 Web Audio API 是否可用并降级
AudioContext 和 webkitAudioContext 是 Web Audio 的核心，但兼容性比基础 Audio 差得多。IE 完全不支持；Android 4.4–5.0 的 WebView 需要前缀；iOS Safari 6–12.1 要求用户手势激活上下文。
检测顺序很重要：先查 window.AudioContext，再查 window.webkitAudioContext，最后 fallback 到 HTMLAudioElement。不能只靠 typeof AudioContext !== 'undefined' 就认为可用——它可能被创建但处于 suspended 状态。
- 创建后立即检查
context.state：若为'suspended'，需绑定用户手势事件（如click）并调用context.resume() - Web Audio 播放短音效更精准（毫秒级调度），但内存和 CPU 开销明显高于
Audio元素，小项目不必强上 - 注意：
OfflineAudioContext在 Safari 中长期存在 bug，生成 PCM 数据时可能静音，生产环境慎用
真正麻烦的从来不是“能不能播”，而是“什么时候播、以什么方式播、播失败了怎么不卡住 UI”。格式检测容易假阳性，自动播放策略每年都在变，而用户不会管你用了哪个 API——他们只听得到第一声有没有响。
