直接使用 标签加载 mp3 会导致内存激增，因浏览器启动解码器线程、分配2–3倍文件大小的缓冲区，并维持dom引用链；即使preload="none"或调用pause()也无法释放资源。
单纯用 <audio></audio> 标签插入 MP3，不加干预，10MB 音频文件可能让内存涨 30–50MB——不是文件大小决定的，是浏览器解码器、缓冲区、DOM 引用三者叠加的结果。
为什么 <audio src="xxx.mp3"></audio> 一挂就吃内存
浏览器加载 MP3 后会做三件事：启动解码器线程、分配音频缓冲区（常达文件大小 2–3 倍）、在 DOM 中维持完整节点引用链。哪怕你设了 preload="none"，只要标签在 DOM 里，这些资源就一直挂着；pause() 或 currentTime = 0 完全不释放解码器和缓冲区。
- 实测 Chrome 中一个未播放但已加载的
<audio></audio>元素，performance.memory.usedJSHeapSize稳定增加 8–12MB -
src指向远程 URL 时更危险：预加载阶段就可能触发后台解码，尤其在 iOS Safari 中无法中断 - 多个音频标签共存时，每个都独立维护解码器，CPU 占用呈线性上升，非简单叠加
复用 <audio></audio> 元素比反复创建更省
不要每次播放都 document.createElement('audio')，全局只留 1–2 个实例，通过切换 src 复用。关键在“切换前重置”，否则旧缓冲区残留、解码器状态混乱，反而更耗资源。
- 切换前必须调
audio.pause()→audio.src = ''→audio.load()，缺一不可 -
load()是核心：它清空已解码缓冲区、重置解码器状态，比单纯改src有效得多 - 若音频需循环或长时播放，避免用
loop=true，改用onended回调中手动play()，防止底层逻辑累积状态 - 不再使用时，务必
audio.remove()并确保无 JS 变量持有该引用（如const player = audio后没置null）
用 AudioContext 替代 <audio></audio> 的真实代价
很多人以为 Web Audio API 更“高级”所以更轻量，其实相反：AudioContext 默认持续运行，即使没声音输出，音频线程也保持活跃，后台 CPU 占用明显高于静默的 <audio></audio> 元素。
- 仅当需要音效混音、实时滤波、精确时间控制时才用
AudioContext；纯播放背景音乐/语音，<audio></audio>是更优解 - 若必须用，务必配合
visibilitychange监听，在页面隐藏时调ctx.suspend()，切回前台再ctx.resume()（注意：需用户手势触发） - 千万别在每次播放时新建
AudioContext实例——它创建成本高，且关闭不彻底易致内存泄漏 - 用完后不能只调
close()，必须先stop()所有节点、disconnect()所有连接、移除事件监听、最后ctx = null
真正压内存的从来不是 HTML 标签本身，而是你没切断的引用链：DOM 节点、解码器句柄、闭包捕获的上下文。删掉一个没清理的 <audio></audio>，可能比加十个新标签还危险。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
