SharedArrayBuffer 结合 Web Audio API 可实现接近硬件级实时响应，关键在于 AudioWorklet 线程与计算线程通过原子操作协同读写同一块内存，跳过序列化与事件循环排队，将延迟压入音频块调度间隙。
SharedArrayBuffer 结合 Web Audio API 可以突破传统音频处理的延迟瓶颈，实现接近硬件级的实时响应（通常
确保 SharedArrayBuffer 启用与安全上下文
SharedArrayBuffer 在现代浏览器中默认被禁用，必须显式启用跨源隔离策略：
- 服务器需返回两个关键响应头：Cross-Origin-Embedder-Policy: require-corp 与 Cross-Origin-Opener-Policy: same-origin
- HTML 页面需通过
<iframe>或new Worker(..., { type: 'module' })加载，且不能降级到非隔离上下文 - 可通过
if (typeof SharedArrayBuffer !== 'undefined') {...}检测是否可用，不可仅依赖 User Agent 判断
构建共享音频缓冲区与内存布局
SharedArrayBuffer 本身不带类型信息，需配合 Float32Array 或 Int16Array 视图使用，并预留控制字段：
- 分配足够大小的缓冲区，例如：48kHz × 2 通道 × 128 样本 ≈
new SharedArrayBuffer(48 * 2 * 128 * 4)（单位字节） - 推荐结构化布局：前 4 字节为原子计数器（
Atomics.load(view, 0)表示当前写入位置），后接连续音频样本数据 - 主页面与 Worker 共享同一视图实例，避免重复构造；Worker 中用
postMessage(buffer, [buffer])传递引用而非拷贝
Web Audio 端对接：ScriptProcessorNode 已废弃，改用 AudioWorklet
AudioWorklet 是目前唯一支持 sub-millisecond 定时调度 + 直接访问共享内存的合法方式：
- 注册自定义 processor：
audioContext.audioWorklet.addModule('processor.js') - 在 processor 内部通过
this.sharedBuffer = port.postMessage(...)接收 SharedArrayBuffer，并创建Float32Array视图 - 重写
process(inputs, outputs, parameters)：从共享视图读取新样本，经算法处理后直接写入outputs[0]，避免中间拷贝 - 务必调用
Atomics.notify()通知主线程/Worker 数据已就绪，否则可能触发忙等待或丢帧
同步策略与常见陷阱规避
低延迟 ≠ 无延迟，错误的同步会引入抖动甚至崩溃：
- 禁止在 AudioWorklet 的
process()中执行任何异步操作（如fetch、setTimeout）、GC 触发操作（如创建对象、字符串拼接）或非原子内存访问 - 使用
Atomics.wait()+Atomics.notify()实现生产者-消费者模式，但等待超时必须设为 0（即轮询）或极小值（如 1μs），避免阻塞音频线程 - 音频上下文需在用户手势（如 click/touch）后启动，且不可被 suspend；建议用
audioContext.resume().catch(e => console.warn('resume failed', e))显式恢复 - 采样率需与 AudioContext 一致（如
new AudioContext({ sampleRate: 48000 })），否则 resample 会引入不可控延迟
不复杂但容易忽略。核心是让 AudioWorklet 线程和计算线程通过原子操作协同读写同一块内存，跳过序列化与事件循环排队，把延迟压进音频块调度间隙里。
