AudioContext 与 AnalyserNode 结合可实时获取音频时域/频谱数据，需通过 createMediaElementSource 绑定 ，设置 fftSize 和 smoothingTimeConstant，用 getByteTimeDomainData 获取波形并中心化绘制于 Canvas。
用 AudioContext 和 AnalyserNode 实时获取音频频谱数据
Canvas 本身不提供音频分析能力，必须靠 Web Audio API 搭配。核心路径是：AudioContext → createMediaElementSource（绑定 <audio></audio>）→ analyser → getByteFrequencyData 或 getByteTimeDomainData。注意：不能直接读取 <audio></audio> 的原始 PCM，必须走 Web Audio 节点链。
常见错误是漏掉 analyser.fftSize 设置——默认值为 2048，但波形图通常用时域数据（getByteTimeDomainData），这时 fftSize 决定采样点数（如设为 256，则每次拿到 256 个 0–255 的幅度值），值太小会失真，太大则渲染卡顿。
关键点：
-
analyser.smoothingTimeConstant控制响应速度，默认 0.8；设为 0 可获得更“生硬”但更实时的波形，适合节奏可视化 - 必须在用户手势（如 click、touchstart）后才允许启动
AudioContext，否则多数浏览器会静音或报DOMException: The audio context was not allowed to start -
getByteTimeDomainData返回的是时域波形（类似示波器），而getByteFrequencyData是频谱（类似均衡器），别混用
Canvas 绘制波形的两种常用模式：线段连接 vs 填充路径
拿到 Uint8Array 数据后，怎么画？不是所有点都值得画满 canvas 宽度——要缩放映射。假设 canvas 宽 600px，数据长度 256，那就每 ~2.34px 画一个点，用 lineTo 连接比逐点 fillRect 更高效。
立即学习“前端免费学习笔记（深入）”；
典型误区是直接把 0–255 映射到 canvas 高度（如 200px），结果波形挤在中间、上下留白多。更自然的做法是把数据中心化：把 128 当作零点，往上画正向，往下画负向，再整体平移居中。
示例片段（简化）：
const width = canvas.width;
const height = canvas.height;
const centerY = height / 2;
const data = new Uint8Array(analyser.frequencyBinCount);
analyser.getByteTimeDomainData(data);
<p>ctx.clearRect(0, 0, width, height);
ctx.beginPath();
ctx.moveTo(0, centerY);</p><p>for (let i = 0; i < data.length; i++) {
const x = (i / data.length) * width;
const y = centerY + (data[i] - 128); // 中心化偏移
ctx.lineTo(x, y);
}
ctx.stroke();
<audio></audio> 元素与 AudioContext 的绑定必须用 createMediaElementSource
不能用 fetch + arrayBuffer + decodeAudioData 来替代——那样只能播放一次，无法持续流式分析。真实场景下，必须让 <audio></audio> 作为 Web Audio 的源头。
绑定代码极简，但容易漏掉两件事：
- 绑定前确保
<audio></audio>已加载元数据（监听loadedmetadata事件），否则createMediaElementSource可能报错 - 绑定后不要调用
audio.play()多次——Web Audio 节点链只认第一次的播放状态；后续控制应通过audio元素本身（如pause()、currentTime） - 移动端需注意：Safari 对自动播放限制更严，即使有用户手势，也可能要求
audio.muted = false且audio.volume > 0才允许发声
性能瓶颈常出在 requestAnimationFrame 频率和数据长度不匹配
每帧都调用 getByteTimeDomainData 没问题，但若 canvas 尺寸大、数据长度高（如 fftSize = 2048），绘图循环会吃 CPU。实测发现：256 点 + 60fps 是多数设备的舒适区。
另一个坑是没做节流——比如用户拖动进度条时，timeupdate 事件高频触发，但波形绘制没必要同步频率。建议只在 requestAnimationFrame 回调里统一取数绘图，和播放逻辑解耦。
还有兼容性细节：
- Firefox 不支持
getByteTimeDomainData的某些旧版本，可用getFloatTimeDomainData替代（返回 -1 到 1 的浮点数），再手动缩放到 0–255 - Chrome 90+ 对
analyser的fftSize有最小值限制（至少 32），设太小会静默失败 - 如果波形完全不动，先检查
analyser.connect(context.destination)是否误连——它不该连到输出，只用于分析
真正难的不是画出来，而是让波形响应及时、不跳变、不卡顿，同时适配不同音频源的响度差异——这得靠动态归一化或 RMS 计算，而不是简单用原始字节值。
