游戏音效暂停后不能恢复？分清 AudioContext suspend 与 close

退出面板时音效停了，再打开却无法恢复。先确认暂停操作作用于单个播放实例，还是整个AudioContext，以及它当前的真实状态。文件能正常解码，并不能证明旧上下文仍可继续使用。

暂时暂停不等于关闭

MDN的suspend说明将其定义为暂停上下文时间推进；resume说明用于恢复，并明确已关闭的上下文会导致其Promise拒绝。它们不是单个音效的音量开关。

close说明描述释放系统音频资源并停止处理；仍被引用的相关对象并不会因此全部自动释放。把close当作临时暂停，再对同一上下文resume，不是等价的生命周期操作。

给控制按钮一个清楚的契约

1. 记录AudioContext实例及操作前state，区分正在运行、已暂停和已关闭。
2. 记录按钮实际调用的方法，不凭按钮文字推断实现。
3. 等待相应Promise成功或失败，再更新界面和业务状态。
4. 再次进入场景时，确认继续使用有效上下文还是由明确的初始化流程创建新对象与连接。

这里讨论采用Web Audio API的接入，不认定Tooliva内部的具体实现，也不宣布当前工具有关闭故障。浏览器还可能出现其他状态或播放限制，不应只写三个状态的无条件恢复循环。

区分整个上下文与单个声音

暂停共享上下文会影响使用它的音频流程，不能默认等于仅停止一个面板试听。由项目负责人明确背景音乐、音效和界面试听的所有者关系，避免一个组件退出就关闭其他功能仍在使用的共享对象。

恢复上下文也不等于已经结束的一次性播放节点自动重播；相关阶段另见AudioBuffer与重播节点检查。保留生命周期与播放实例两份记录，避免重复下载掩盖状态错误。

按真实使用路径验收

固定一份从音效工具保存的样本，检查打开、暂停、恢复、退出和再次进入，并覆盖实际错误分支。按浏览器要求通过用户操作恢复播放，不绕过保护机制。

观察真实state、Promise和可听结果，再检查最终清理。close成功不代表进程内存立刻归零；本篇未执行浏览器内存或后台电量测试，也不承诺统一的重建策略。