将基于ScriptProcessor的WebAudio应用迁移至AudioWorklet的技术求助

我最近在把自己的WebAudio应用从已废弃的ScriptProcessor（2014年起就被弃用了）迁移到AudioWorklet（Chrome 64之后推出的新标准），过程中碰了不少钉子。我特意找了一篇优质文章里的两个示例来拆解核心差异，帮大家搞懂我到底卡在哪了：

一、ScriptProcessor的实现逻辑 #

ScriptProcessor的核心是同步回调式的实时填充：它会在音频播放的过程中，不断触发回调函数，每次回调里我都能实时生成或加载新的音频数据，直接填充到当前的播放缓冲区里——相当于边播边“喂”数据，非常适合需要动态生成音频的场景，比如实时音效合成、流媒体音频处理。

举个简化的代码片段感受下：

const scriptNode = audioContext.createScriptProcessor(4096, 1, 1);
scriptNode.onaudioprocess = (event) => {
  const outputBuffer = event.outputBuffer.getChannelData(0);
  // 实时生成音频数据填充到outputBuffer
  for (let i = 0; i < outputBuffer.length; i++) {
    outputBuffer[i] = Math.random() * 2 - 1; // 生成白噪声
  }
};
scriptNode.connect(audioContext.destination);

二、预填充缓冲区的播放方式 #

另一种常见的音频播放逻辑是提前生成全部数据：先把所有要播放的音频数据一次性生成好，塞进AudioBuffer里，再用AudioBufferSourceNode去播放——这种方式适合固定内容的音频，比如预录制的音效、提前渲染好的音乐。

代码大概是这样：

const buffer = audioContext.createBuffer(1, 44100 * 2, 44100);
const channelData = buffer.getChannelData(0);
// 提前填充全部数据
for (let i = 0; i < channelData.length; i++) {
  channelData[i] = Math.random() * 2 - 1;
}
const sourceNode = audioContext.createBufferSource();
sourceNode.buffer = buffer;
sourceNode.connect(audioContext.destination);
sourceNode.start();

核心差异与我的迁移困境 #

这两种方式的核心区别很明显：

• ScriptProcessor是流式实时填充：播放过程中持续生成新数据，没有提前准备好完整的音频文件也能播
• 预填充方式是一次性生成全量数据：必须先把所有数据准备好才能开始播放

而我的应用刚好是依赖ScriptProcessor那种实时流式处理的逻辑，比如要根据用户的操作实时生成变化的音效。但AudioWorklet的工作机制和ScriptProcessor完全不同：它运行在独立的音频线程里，不能直接访问主线程的DOM或同步数据，只能通过MessagePort和主线程异步通信——这就导致我之前的同步回调逻辑完全没法直接移植，一开始折腾了好久都没搞定怎么在AudioWorklet里实时获取主线程的动态数据，再生成对应的音频输出。

内容的提问来源于stack exchange，提问作者Niek