用 web worker 拆分实时音调识别任务可避免主线程卡顿：worker 专注 fft、峰值检测等信号处理，主线程负责数据调度与渲染，通过 postmessage 协同，配合节流、音名映射和设备适配确保稳定高效。
直接在主线程做实时频率解析和音调识别，容易卡顿、掉帧，尤其在低端设备或长音频分析场景下。用 Web Worker 拆分计算任务是更稳的路径——它把 FFT、峰值检测、基频估算等重操作移出 UI 线程，只让主线程负责数据调度和结果渲染。
Worker 中完成核心信号处理
Worker 不接触 DOM，也不访问 AudioContext，只专注数字信号处理：
- 接收主线程传入的 PCM 数据片段（Float32Array），通常是每 1024 或 2048 个采样点一帧
- 做预加重（pre-emphasis）抑制低频衰减，再加汉宁窗（Hanning window）减少频谱泄漏
- 调用轻量级实数 FFT（如自研或
fft-js）计算频谱幅度，输出长度为N/2的能量数组 - 在频谱中找主峰：跳过直流分量（索引 0），过滤掉低于 50Hz 或高于 1500Hz 的无效区，再用二次插值精确定位峰值频率
- 对连续多帧结果做简单跟踪（如移动平均 + 阈值判稳），输出当前估计的基频（单位 Hz）和置信度
主线程与 Worker 的协同机制
不能让 Worker 盲目跑满，需配合音频流节奏精准供数：
- 主线程监听
analyser.getByteTimeDomainData()或从ScriptProcessorNode（已弃用，可用AudioWorklet替代）拿到原始波形，切片后用postMessage()推送至 Worker - Worker 处理完一帧后，通过
postMessage({ freq: 440.3, confidence: 0.92 })回传，主线程用onmessage接收并更新 UI（如显示 “A4”、“C#5”） - 为防消息堆积，可设节流：仅当上一帧结果已处理完毕，才发下一帧；或 Worker 内部用
setTimeout控制最小间隔
音调映射与人声/乐器适配
识别出频率只是第一步，要转成用户能理解的音名，还需上下文判断：
- 按十二平均律公式
noteIndex = round(12 * log2(freq / 440) + 69)计算 MIDI 音符编号，再查表得音名（如 69 → A4） - 人声范围通常在 80–1100Hz，吉他空弦为 E2(82Hz) 到 E4(330Hz)，可据此动态调整搜索区间，提升准确率
- 若连续 5 帧落在同一半音内且置信度 > 0.85，才触发“已稳定识别”状态，避免抖动误判
实际部署注意点
Worker 路径、数据格式、容错都要提前对齐：
- Worker 文件需独立 JS 文件（如
pitch-worker.js），不能是内联脚本；创建时用new Worker('pitch-worker.js') - 传输 Float32Array 时启用
transferable选项（postMessage(data, [data.buffer])），避免拷贝开销 - Worker 内不支持
console.log，调试用self.postMessage({ debug: '...' })回传到主线程打印 - 移动端需注意：iOS Safari 对长时间运行的 Worker 有休眠策略，建议识别逻辑保持短平快，单帧处理控制在 8ms 内
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
