audioworklet 通过将音频处理下沉至高优先级独立线程、直采原始 pcm、精细配置 audiocontext 参数，并接受平台限制做折中，显著降低延迟。
AudioWorklet 能显著降低音频处理延迟，核心在于它绕开了主线程和默认音频处理链的瓶颈，把计算直接下沉到浏览器的音频渲染线程中执行。
脱离主线程调度
传统 Web Audio 节点（如 ScriptProcessorNode，已废弃）或用 requestAnimationFrame 拦截音频流，都运行在主线程。一旦页面有复杂 JS 任务、重绘或垃圾回收，就会打断音频回调，引入几十毫秒甚至上百毫秒的抖动。
- AudioWorklet 运行在独立的、高优先级的音频工作线程中，与页面渲染和 JS 执行完全隔离
- 它的处理器（
AudioWorkletProcessor）由浏览器音频引擎按固定周期（如每 128 样本帧）主动调用，时间精度可达 sub-millisecond 级 - 无需等待事件循环，也不存在主线程阻塞导致的“掉帧”或缓冲堆积
直采原始 PCM，跳过编码与封装
MediaRecorder 或 canvas.captureStream() 等路径会触发浏览器内部编码（如 Opus）、封装（WebM）、再解码，带来不可控延迟（Chrome 中常超 200ms）。
- 用
AudioContext.createMediaStreamSource()接入麦克风流后，通过 AudioWorklet 直接读取Float32Array格式的原始 PCM 数据 - 可自行控制采样率（如固定 48kHz）、帧长（128/256 样本）、数据类型（转为
Int16Array小端序），避免格式转换开销 - 输出可直连 WebSocket 二进制传输，或送入自定义 DSP（如用 WebAssembly 编译的 Maximilian 模块）做实时滤波、AEC 前置处理
精细控制音频上下文参数
延迟不仅来自处理逻辑，更来自 AudioContext 的缓冲配置和调度策略。
- 创建时显式指定
latencyHint: 'interactive'，提示浏览器启用最低延迟音频路径 - 避免调用
resume()过早；先suspend()，等用户手势触发后再恢复，防止后台耗电与资源抢占 - 禁用不必要的节点链（如无意义的 GainNode、ConvolverNode），减少音频图遍历开销
接受平台限制，做合理折中
纯 Web 环境无法突破硬件与系统层限制，低延迟需配合现实约束。
- iOS Safari 不支持 AudioWorklet 输入（无法采集麦克风），只能处理已有流或合成音
- 部分安卓 WebView 或旧版 Chrome 对
AudioWorklet的帧长控制不够稳定，需 fallback 到AudioProcessingEvent（已弃用但仍有支持） - 无内置回声消除（AEC）和噪声抑制（ANS），需前端集成轻量 WASM 模块或依赖服务端补偿
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
