让声音成为明确的第一个行动的一部分
如果游戏默认认为声音已经开始播放，可能会显示静音图标，但实际仍然没有声音。浏览器通常会限制脚本启动的音频，直到用户进行操作；媒体播放请求也可能被拒绝或延迟完成。应在首次交互时确定玩家的音频选择，并根据实际播放结果更新界面。这样行为更可预测，也不会用意外的声音吓到玩家。
测试新页面加载和从另一个选项卡返回。尝试阻止自动播放的浏览器配置、静音系统和缓慢的音频资源。确认游戏的视觉开始不受可选音效的影响，并且如果音频尚未开始，控制标签保持真实。
保持反馈和音频状态一致
不要将对 play() 的成功调用与即时声音输出等同起来。该承诺可能会异步解决，并且浏览器可能会请求许可。处理拒绝，在有用的情况下公开重试操作，并且在只有声音不可用时不报告暗示整个游戏失败的错误。
将用户偏好与运行时权限分开：保存的静音选择是播放器的意图，而当前是否允许播放是浏览器条件。独立测试静音、取消静音、暂停、恢复和场景转换，这样效果就不会在状态更改后意外地以最大音量重新启动。
关于浏览器游戏音频启动的常见问题
我可以在页面加载后自动播放游戏音乐吗？
不要假设一定能自动播放。自动播放规则可能会阻止未经用户操作启动的有声媒体和 Web Audio。应提供由玩家主动触发的操作，并处理播放失败。
如果播放被阻止，声音按钮应该显示什么？
根据实际观察到的结果，显示准确状态，例如“声音已关闭”或开启声音的操作。MDN 建议处理 play() 返回的 Promise，而不要假设播放已经开始。
延伸阅读
发现信息过时了？ 报告需要更正的内容