必须用 Web Audio API 提取真实波形:加载二进制音频→decodeAudioData 得 AudioBuffer→getChannelData(0) 获取 -1.0~+1.0 浮点采样点;实时分析用 AnalyserNode + getByteTimeDomainData();Canvas 绘制需降采样取极值或 RMS,避免失真卡顿;iOS 需用户手势触发 AudioContext 和解码。
<audio> 自带属性HTML 原生 <audio> 标签不提供波形数据——它只负责播放和控制。想画波形,必须走 Web Audio API 这条路:加载音频 → 解码为 PCM → 用 AnalyserNode 或 AudioBuffer 读取时域/频域数据 → 交给 Canvas 渲染。
常见错误是试图监听 timeupdate 事件然后查 audio.currentTime 来“估算”波形,这完全无效——没有采样点,只有时间戳。
fetch() 或 FileReader 加载音频二进制数据,再用 context.decodeAudioData() 解码AudioBuffer,其 getChannelData(0) 返回的是 -1.0 ~ +1.0 的 Float32Array,这才是真实波形采样点AnalyserNode 配合 getByteTimeDomainData()
Canvas 2D 绘制波形时,别直接画全部采样点一段 3 分钟的 44.1kHz WAV 文件有约 790 万个采样点;Canvas 画布宽度通常就 800px 左右。把 790 万点塞进 800 像素,不是性能问题,是逻辑错误:会严重失真、卡死、甚至触发浏览器内存回收。
正确做法是「降采样」:对每 N 个连续采样点,取最大值(peak)和最小值(valley),组成一对上下包络线点。这个 N 就是缩放比:Math.ceil(buffer.length / canvas.width)。
立即学习“前端免费学习笔记(深入)”;
Math.max(...slice())——大数组会爆栈;改用循环找极值Math.sqrt(sum(x²) / count)
AudioBuffer 的 numberOfChannels:单声道直接用 channel 0;双声道建议先混音((left + right) / 2),否则左右声道错位导致波形抖动requestAnimationFrame 实时绘制时,analyser.getByteTimeDomainData() 返回的是 256 字节很多人卡在这儿:明明设了 analyser.fftSize = 512,但 getByteTimeDomainData() 总是返回长度为 256 的 Uint8Array,且数值范围是 0–255,不是 -128–127。这是因为该方法强制使用 fftSize / 2 的缓冲区,并做 0–255 映射(0 对应 -1.0,128 对应 0.0,255 对应 +1.0)。
(byteValue - 128) / 128 得到归一化浮点值即可requestAnimationFrame 回调里调一次就够了,重复调不会提高精度,只会浪费 CPUUint8Array 缓冲区——每次调用前要 new 一个新数组,或用 array.fill(128) 重置中性值decodeAudioData 可能静默失败iOS Safari 对自动播放策略极其严格:未由用户手势触发的音频上下文,即使已解码成功,后续调用 decodeAudioData 也可能返回 Promise pending 不 resolve,也不 reject。这不是代码 bug,是权限限制。
AudioContext 创建和首次 decodeAudioData 调用,都发生在用户点击/触摸回调内(例如按钮 onclick)autoplay 和 muted,iOS 仍可能拒绝解码非静音音频The AudioContext was not allowed to start —— 这是明确信号,得补用户交互钩子波形可视化真正的复杂点不在算法,而在音频生命周期管理:解码时机、上下文状态、采样精度取舍、移动端策略适配。漏掉任意一环,画出来的都不是波形,是猜的形状。