play()函数本身不限制内存，实际内存占用取决于音频资源加载方式；反复创建audio实例或解码大wav文件易致内存上涨甚至崩溃，需用流式接入、预处理压缩、分段加载及状态机式全链路管理。
play() 函数本身不设内存限制，但音频资源加载方式决定实际内存占用
浏览器或框架里的 play() 只是触发播放行为，它不负责解码、不分配音频缓冲区——真正吃内存的是你用 Audio 对象加载的源文件，尤其是通过 src 直接赋值或 AudioContext.decodeAudioData() 解码后的 AudioBuffer。
常见错误现象：页面反复调用 new Audio(src).play() 播放同一段 MP3，内存持续上涨，DevTools 中看到多个未释放的 Audio 实例；或者用 decodeAudioData() 加载大 WAV 文件后卡顿甚至崩溃。
- 语音类短音频（Audio 构造函数 +
src，启用preload="auto"，避免提前解码；播放完可手动置audio.src = ""辅助 GC - 需精确控制或循环播放的音频（如游戏音效）：用
AudioContext.decodeAudioData()解码为AudioBuffer，但务必复用同一个AudioBufferSourceNode，不要每次play()都新建节点 - 背景音乐等长音频：必须用
Audio元素流式播放，禁用decodeAudioData()—— 一个 5MB 的 MP3 解码成 PCM 后可能暴涨到 60MB+ 内存
Unity 中 AudioSource.play() 的内存陷阱在 AudioClip 加载模式
Unity 的 AudioSource.Play() 不直接分配内存，但背后 AudioClip 的 Load Type 设置会彻底改变内存行为：
-
Decompress On Load：WAV/PCM 类型强制全量解压进内存，1 分钟 44.1kHz/16bit 立体声 WAV 占用约 10MB RAM；适合极短、高频播放的音效（如点击声），但绝不能用于长音频 -
Compressed In Memory：ADPCM 或 Vorbis 格式保留在内存中压缩状态，播放时实时解压；ADPCM 压缩比约 3.5:1，CPU 开销低；Vorbis 压缩比更高（~10:1），但解码 CPU 成本明显上升，适合中等长度、播放频率不高的音频 -
Streaming：MP3/AAC 文件仅缓存当前播放窗口（通常几秒），内存占用稳定在几百 KB，但首次播放有轻微延迟；唯一适合 BGM 和长语音的选项
容易踩的坑：把 20MB 的 MP3 导入 Unity 后没改 Load Type，默认变成 Decompress On Load，结果打包后内存暴涨，iOS 上直接被系统 kill。
Web Audio API 中 decodeAudioData() 是内存爆点，不是 play()
很多人以为 play() 卡顿是因为“播放太慢”，其实是 decodeAudioData() 在主线程同步解码大文件导致的阻塞。这个函数会把整个压缩音频（如 MP3）解成原始 PCM 数据，内存占用 = 采样率 × 位深 × 声道数 × 时长。
例如一段 3 分钟 MP3（44.1kHz / 16bit / stereo）解码后约为：44100 × 2 × 2 × 180 ≈ 31.8MB PCM 数据 —— 这还没算 JS 对象开销。
- 别在主线程调用
decodeAudioData()处理 >10 秒的音频；改用Audio元素 +MediaElementAudioSourceNode流式接入 Web Audio - 必须用
AudioBuffer时，优先选 ADPCM 编码的 WAV（Unity 导出支持），或用 FFmpeg 预处理为低采样率（如 22050Hz）、单声道、16bit 的 WAV - Chrome 120+ 支持
AudioDecoder（实验性），可在 Worker 中异步解码，但目前兼容性差，不建议生产使用
移动端 audio.play() 失败常因内存不足触发静音策略
iOS Safari 和 Android Chrome 在后台标签页或低内存状态下，会主动中断音频上下文、清空已解码数据，导致后续 play() 报错 DOMException: The element has no supported sources 或静音无响应。
这不是代码写错了，而是系统级保护机制。此时检查 audio.readyState 往往是 0（HAVE_NOTHING），且 audio.buffered.length === 0。
- 不要依赖自动播放：用户手势触发后，立即调用
audio.play().catch(e => console.warn("play failed:", e))，并准备 fallback（如显示“点击继续播放”按钮） - 长音频分段加载：用
MediaSource Extensions (MSE)实现分片加载与播放，避免一次性请求整个文件 - 监听
webkitvisibilitychange和memorypressure（Android）事件，在切后台前暂停、释放AudioContext，恢复前台时重建
真正难处理的不是怎么播，是怎么在内存紧张、策略多变的移动端，让音频既不崩也不哑——这需要把加载、解码、播放、回收全链路当成一个状态机来设计，而不是只盯着 play() 那一行。
