Web Audio API 在设备静音模式下无声的根本原因

问题出在系统层面。当 iPhone 或 iPad 处于系统级静音模式时——不管是拨动物理开关到静音侧，还是在控制中心开启了“静音模式”——Web Audio API 创建的 AudioContext 就会默认被强制静音。

这时候，哪怕你 Ja vaScript 里正确调用了 audioContext.resume()，用户也完成了一次点击，音频缓冲也加载完了，它就是不出声。

注意，这不是权限问题，而是 iOS/macOS 的底层音频路由策略直接把 Web Audio 的输出通道给掐断了。

验证当前是否处于系统静音模式

怎么判断？在 iPhone 或 iPad 上，从右上角向下滑动打开控制中心，看看顶部状态栏右侧有没有一个月牙形的【静音模式图标】。

如果有，说明硬件级静音已经开启，Web Audio API 必然不工作。这就是个硬门槛，绕不过去。

要是你的设备有响铃/静音物理开关，请确认这个开关是朝前拨的（不露出橙色）。否则，不管代码怎么优化，它都保持静默。

解除静音后仍无声？检查 AudioContext 初始化时机

还有一种情况：设备没静音，但还是没声音。那就要看 AudioContext 是什么时候创建的。Web Audio API 要求，AudioContext 必须由明确的用户手势触发才能正常运行。

简单说，你得在用户点击按钮的那一刹那去创建它。如果代码放在 DOMContentLoaded 或 load 事件里，那上下文就会处于“挂起”状态，resume() 也会静默失败。

方法一：用一次点击解封上下文

在按钮的点击事件里执行：const audioContext = new (window.AudioContext || window.webkitAudioContext)(); audioContext.resume();。注意，必须放在这个回调里，其他地方无效。

方法二：监听首次交互后自动恢复

给 document 绑定一个 click 或 touchstart 事件，在回调里创建并 resume() 上下文，然后移除监听器。这样可以避免重复调用 resume() 报错。

绕过静音限制的替代方案：改用 HTML5

如果实在搞不定，或者业务场景比较简单，可以考虑换个路子：用 HTML5 的 标签。

这个东西不受系统静音模式的强制屏蔽。只要用户完成一次交互（比如点一下播放按钮），就能正常发声，并且也能响应系统音量滑块调整。