AudioWorklet比Web Worker更适合实时音频处理，因其运行在音频渲染线程，具备微秒级定时精度和零缓冲抖动；Web Worker存在1–4ms调度延迟，无法满足44.1kHz采样硬实时要求，易导致断续、相位跳变或卡死。
不能直接在 Web Worker 中处理音频频率均衡过滤，因为 Web Audio API 的核心对象（如 AudioContext、BiquadFilterNode）**只能在主线程创建和操作**。Worker 没有访问音频硬件或音频图的能力，也无法调用 `createBiquadFilter()` 或连接节点。但你可以把**计算密集型预处理任务**交给 Worker，再把结果传回主线程用于实时滤波。
哪些音频均衡逻辑能放进 Worker
Worker 适合做不涉及实时音频图操作、但耗时的前置计算，例如：
- 离线分析音频文件频谱特征（如 FFT 幅度分布），为均衡参数提供依据
- 批量生成自适应 EQ 曲线（比如根据用户听音环境建模后输出一组 frequency/gain/Q 值）
- 解析并转换第三方 EQ 配置文件（如 JSON 格式的 10 段参数），做校验、归一化、范围限制
- 对长音频 Buffer 进行分段 FFT + 统计，输出每段建议的低频提升量（供主线程动态调整 filter.gain）
Worker 与主线程如何协作实现均衡控制
典型流程是“计算分离、参数传递、主线程执行”：
- 主线程加载音频后，将关键元数据（如采样率、时长、声道数）和用户设置发给 Worker
- Worker 执行算法（例如用 FFTW.js 或纯 JS 实现的频谱分析），输出一组目标参数：[{freq: 120, gain: 3.2, q: 1.4}, ...]
- 主线程监听
worker.onmessage，收到后遍历该数组，逐个调用bassFilter.gain.setValueAtTime(...)等更新滤波器 - 所有 BiquadFilterNode 仍由主线程创建、连接、管理；Worker 不触碰 AudioContext 或任何节点实例
实际编码要点
避免常见误区，确保通信高效稳定：
立即学习“前端免费学习笔记（深入）”；
- 传输数据用
postMessage(..., [transferList])避免拷贝大数组；例如传 Uint8Array 频谱数据时加上 transfer 列表 - Worker 内不要尝试 new AudioContext() 或调用任何 Web Audio 方法，会报
ReferenceError - 主线程接收参数后，必须检查是否处于
audioContext.state === 'running'，否则需先resume() - 若需连续反馈（如实时频谱+EQ 调整联动），Worker 可定时 postMessage 发送摘要（如“中频能量偏高 12%”），主线程据此微调 peaking filter.gain
为什么不推荐在 Worker 里做实时滤波计算
实时音频处理要求严格的时间精度（通常需在 10ms 内完成一帧），而 Worker 与主线程通信存在不可忽略的延迟，且无法保证调度时机。Web Audio 的音频渲染线程是独立且高优先级的，强行绕过它会导致：
- 音频卡顿或跳帧（buffer underrun）
- 相位错乱（因滤波参数未按 audioContext.currentTime 对齐更新）
- 无法利用浏览器内置的优化（如 SIMD 加速的 biquad 计算）
