音效文件很小，加载后内存却变大？分清下载文件与 AudioBuffer

音效文件很小，游戏载入后的内存却比预期大。先确认观察的是下载文件、解码缓冲还是页面进程。三个层面的KB数，不能直接用来判断是否泄漏。

AudioBuffer 不是原始压缩文件

MDN AudioBuffer参考说明采样数据采用非交错32位浮点PCM，多声道分别存储。length是每个声道的采样帧数，不是全部声道采样值相加。

这一表示下，采样载荷可按length × numberOfChannels × 4字节估算。它不包含对象、解码临时空间和其他浏览器开销，不是操作系统实际驻留内存测量。

用条件例子检查计算

假设缓冲恰好2秒、每秒48000采样帧、2声道，则length为96000，载荷96000 × 2 × 4 = 768000字节，即750 KiB。这是算术假设，不是Tooliva默认参数或实测。

已经从真实length出发，就不要再乘时长或把声道算两遍。先解释数字，比看到大值就反复压缩文件更有用。

输入应来自解码后的属性

MDN decodeAudioData文档说明结果会重采样到上下文采样率。因此原文件标签不能自动代替实际AudioBuffer.sampleRate与length。

若问题是两个WAV磁盘大小不同，参照采样率、位深和声道的文件大小检查。那个模型针对另一种表示，不能直接当作当前解码缓冲内存。

按独立缓冲与持有者调查

1. 固定文件和解码条件，记录真实length、声道与采样率。
2. 核对缓存内独立解码结果与仍持有引用的对象。
3. 区分共享缓冲的播放实例、真正数据副本和其他处理节点。
4. 受控观察加载、反复播放和场景退出，核对释放策略。

播放十次不自动等于十份PCM副本；清空一个变量也不保证内存立即下降。需结合真实引用和分析工具，不以单张任务管理器截图认定泄漏。

素材与缓存策略分开验收

从音效工具固定一个版本，用同一份导出测试接收项目。降低下载字节，不自动缩小帧数、声道和表示方式都相同的解码载荷。

本文未测量浏览器堆内存，不设跨设备统一缓存上限。根据实际数据量、复用需求和离场行为决定策略，再确认声音与体验保留。