web workers 不能直接进行实时音频合成或滤波，但可通过预处理和参数生成提升性能：适合移入 worker 的任务包括分段 fft 分析、eq 配置解析、滤波器参数批量生成及离线音效渲染；audiocontext 等 web audio api 对象仅主线程可用，因需精确时序与硬件访问；协作模式为“算在后台、控在前台”，主线程负责节点操作，worker 仅输出参数；推荐用 comlink 简化通信。
Web Workers 不能直接做实时音频合成或滤波，但能显著提升复杂音频处理的整体性能和响应性——关键在于任务拆分：把耗时计算挪到后台线程，把音频图操作严格留在主线程。
哪些音频任务适合放进 Worker
Worker 的价值不在“实时播放”，而在“预处理”和“参数生成”。适合移出主线程的任务包括：
- 对长音频文件做分段 FFT 分析，统计各频段能量分布，为动态均衡提供依据
- 解析第三方 EQ 配置（如 JSON 格式的 31 段参数），做范围校验、单位转换与插值平滑
- 基于用户环境建模（如房间尺寸、麦克风响应）批量生成自适应滤波器参数组（frequency/gain/Q）
- 离线渲染音效预设（如混响早期反射序列、非线性失真查找表），生成可复用的 AudioBuffer 数据
为什么不能在 Worker 里创建 AudioContext 或连接节点
Web Audio API 的核心对象（AudioContext、BiquadFilterNode、AnalyserNode 等）仅在主线程可用。Worker 中调用 new AudioContext() 会直接抛出 ReferenceError；尝试 createBiquadFilter() 或 .connect() 均无效。这不是限制，而是设计使然：音频图必须运行在与渲染同步的上下文中，以保障精确时序和硬件访问权限。
主线程与 Worker 协作的实用模式
典型流程是“算在后台、控在前台”：
- 主线程加载音频后，将采样率、声道数、用户选择的EQ类型等元数据发给 Worker
- Worker 运行纯 JS 或 wasm 实现的频谱分析/参数优化算法，输出轻量级参数数组，例如
[{freq: 85, gain: 2.1, q: 0.7}, ...] - 主线程收到后，检查
audioContext.state === 'running'，再逐个调用filter.gain.setValueAtTime()更新节点 - 大数组传输时使用
postMessage(data, [array.buffer])启用 Transferable，避免内存拷贝开销
用 Comlink 简化通信逻辑
手动写 onmessage/postMessage 易出错且冗长。Comlink 把跨线程调用变成直观函数调用：
- Worker 中
Comlink.expose({ analyze: (buffer) => {...} }) - 主线程中
const workerAPI = Comlink.wrap(...)，然后直接await workerAPI.analyze(audioData) - 自动处理 Promise、Transferable 和错误传播，配合 TypeScript 还能获得完整类型提示
不复杂但容易忽略：所有音频节点创建、连接、start() 和参数调度，必须且只能发生在主线程；Worker 只负责算出“该调什么”，而不是“怎么调”。
