web worker 不适合实时音频缓冲，因其1–4ms调度延迟远超44.1khz下22.7μs样本间隔，导致断续、跳帧、相位错乱，且无法访问audiocontext及音频节点；它仅适用于离线预处理任务。
不能用 Web Worker 处理实时音频合成的缓冲逻辑。
为什么 Web Worker 不适合实时音频缓冲
实时音频缓冲要求微秒级定时精度和帧级同步，而 Web Worker 是独立 JavaScript 线程，与主线程通信存在 1–4ms 的固有调度延迟。在 44.1kHz 采样率下，每个样本间隔仅约 22.7μs，Worker 的延迟远超容许范围，会导致：
- 音频断续、跳帧或相位错乱
- 缓冲区无法严格对齐音频渲染周期（如 128 样本/帧）
- 移动端 Chrome 会主动降频 Worker 中的定时任务（如 requestIdleCallback），加剧抖动
- 无法访问 AudioContext、AudioBufferSourceNode 或任何音频图节点，也就无法直接写入或读取音频缓冲区
Web Worker 在音频场景中的合理用途
它只适用于不依赖实时性、不参与音频渲染管线的离线预处理任务：
- 解析音频文件头（WAV/MP3）、提取 ID3 标签或元数据
- 对已录制完成的音频做批量 FFT 分析，输出频谱统计或均衡建议参数
- 校验并归一化第三方 EQ 配置（如 JSON 中的 frequency/gain/Q 值）
- 大音频文件分片上传前的 SHA-256 计算，避免阻塞主线程
真正适合实时缓冲的方案是 AudioWorklet
AudioWorklet 运行在浏览器的音频渲染线程，与 AudioContext 同步，具备以下关键能力：
- process() 回调由硬件驱动触发，严格按帧执行（例如每 128 样本调用一次）
- 可直接读写 AudioWorkletProcessor 内部的输入/输出通道缓冲区
- 支持通过 parameters 动态更新滤波器参数（如 gain、frequency），实现低延迟响应
- 能配合 Ring Buffer 实现滑动窗口式音频流管理，适配 WebSocket 流式 TTS 场景
若必须用 Worker，只能做“缓冲准备”，不能做“缓冲执行”
例如：接收 WebSocket 推送的 PCM 分块数据，在 Worker 中做解码（如 base64 → Int16Array）、格式校验、长度对齐；完成后将标准化后的 ArrayBuffer 传回主线程，再交由 AudioWorklet 或 AudioBufferSourceNode 播放。整个过程仍需主线程或 Worklet 完成真正的缓冲调度与播放。
