iOS游戏声音无法播放主因是系统策略限制：一是loadedmetadata不触发导致无法播放，因缺少Accept-Ranges响应头或编码不兼容；二是需用户手势授权，touchstart内调用play()才有效；三是AudioContext易suspend且并发解码数限2。
游戏声音在iOS上无法播放，绝大多数情况不是代码写错了，而是被系统策略拦住了——尤其是loadedmetadata事件不触发、音频未获用户手势授权、或格式不兼容这三类问题最常见。
为什么loadedmetadata不触发就播不了？
iOS Safari（以及所有WKWebView内嵌环境）要求音频资源必须完成元数据加载才能进入可播放状态，而loadedmetadata失败往往意味着浏览器根本没解析出时长、采样率等基础信息。这不是bug，是强制的安全策略。
- 常见错误现象：
audio.play()抛出NotAllowedError: The request is not allowed by the user agent，但控制台没报错，audio.readyState停在0或1 - 根本原因：服务端返回的音频响应头缺失
Accept-Ranges: bytes，或使用了iOS不支持的编码（如MP3的VBR变码率、某些FLAC子集） - 实操建议：
– 优先用AAC-LC编码的.m4a文件（iOS原生支持最好）
– Nginx/Apache配置中确保返回Accept-Ranges: bytes和Content-Type: audio/mp4
– 在audio.src赋值后，监听loadedmetadata，**不要直接调play()**；失败时可降级为预加载+用户点击后播放
为什么必须有用户手势才能播放音频？
iOS从iOS 10起强制要求所有自动音频播放（包括autoplay属性）必须由用户真实交互（tap/click）触发，且该交互必须发生在500ms内——这是硬性限制，绕不过。
- 常见错误现象：页面一加载就
audio.play()，静默失败；或用setTimeout延迟100ms再播，依然失败 - 关键细节：手势事件必须是**非委托、非合成、未被preventDefault**的原生事件；
touchstart比click更可靠，尤其在iOS上 - 实操建议：
– 把audio.play()放在document.addEventListener('touchstart', ...)回调里，且只绑定一次
– 首次交互后，可缓存audio实例，后续用audio.currentTime = 0; audio.play()重播
– 不要用new Audio().play()临时创建，iOS对动态创建的音频实例权限更严
为什么游戏音效在iOS上突然“哑火”，但音乐App却正常？
因为游戏常混用多种音频源：背景音乐用Audio标签，音效用Web Audio API，而iOS对两者的调度策略不同——Web Audio的AudioContext在页面切到后台或无交互后会自动suspend，且恢复需用户手势。
- 常见错误现象：切到其他App再切回来，音效全无；或刚打开游戏时第一声不响，点一下屏幕才恢复
- 核心区别：
Audio元素受autoplay策略限制，AudioContext则受suspend/resume生命周期控制 - 实操建议：
– 初始化AudioContext时不要立即创建，等首次touchstart后再new AudioContext()
– 监听document.addEventListener('visibilitychange', () => { if (!document.hidden && audioCtx.state === 'suspended') audioCtx.resume(); })
– 避免在AudioContextsuspend状态下调start()，会静默失败
最容易被忽略的是：iOS对同一域名下并发音频解码数有限制（通常≤2），游戏若同时加载BGM+多个音效+语音提示，很可能部分音频卡在loading状态不动——这时loadedmetadata不会来，canplay也不会触发，得靠audio.networkState === NETWORK_NO_SOURCE去主动探测。
