AudioContext未关闭会导致内存泄漏，需在用户停止播放、组件销毁、页面隐藏时显式调用close()；应全局单例管理、避免重复创建，并在关闭后置null、加状态标记及检查第三方库行为。
AudioContext 未关闭是前端音视频开发中典型的内存泄漏诱因。它本身不直接“吃”大量内存，但会持续持有音频节点、缓冲区、事件监听器及底层系统资源（如音频硬件通道），一旦被全局变量或闭包长期引用，GC 无法回收，进程内存会随使用次数阶梯式上涨。
确认 AudioContext 是否已泄露
打开 Chrome 或 Edge 的 DevTools → Memory 面板，执行以下操作：
- 点击 “Take heap snapshot” 拍摄初始快照
- 播放音频 → 停止 → 销毁相关 UI（如卸载组件）
- 再次拍摄快照，筛选 “AudioContext” 构造函数实例
- 若数量持续增加（尤其在重复操作后仍不归零），基本可判定未正确关闭
必须显式关闭 AudioContext 的三种典型场景
AudioContext 不会因页面隐藏、标签页冻结或组件卸载而自动关闭——它默认存活至页面生命周期结束。以下情况需主动调用 close()：
-
用户主动停止播放：例如点击“暂停”“停止”按钮后，应立即执行
audioContext.close() -
组件/模块销毁时：React 中在
useEffect清理函数、Vue 中在onBeforeUnmount、纯 JS 中在 DOM 移除回调里调用 -
页面可见性切换：监听
visibilitychange，当document.hidden === true且当前无后台音频需求时，可安全关闭（注意：Web Audio 不支持后台播放，关闭无副作用）
避免重复创建与错误复用
频繁新建 AudioContext 是泄漏的常见源头，尤其在交互密集的 UI（如节拍器、音效按钮）中：
- 不要每次点击都
new AudioContext()；应全局单例管理，按需启动（resume()）和暂停（suspend()） - 禁止将 AudioContext 存在全局变量 + 未清理的事件监听器组合（如
window.addEventListener('click', ...)中引用 context） - 若使用 Web Workers 处理音频，Worker 内的 AudioContext 也需在 Worker 终止前手动
close()
补充防御性实践
即使逻辑上已调用 close()，仍建议加一层保护：
- 关闭后立即将引用设为
null，防止后续误用或重复 close 报错 - 封装 Context 管理器，加入状态标记（
isClosed）和幂等 close 方法 - 对第三方音频库（如 Tone.js、Howler.js）检查其文档：Tone.js 默认自动管理，但启用
Tone.context.latencyHint = 'playback'后需更谨慎；Howler.js v2+ 使用Howler.unload()可释放全部上下文
