analysernode 是 web audio api 中获取实时波形或频谱数据的最直接方式，需正确配置 fftsize、smoothingtimeconstant，显式连接节点，并在 audiocontext 运行时读取数据；canvas 绘制波形优于 svg，注意复用 uint8array、关闭抗锯齿、适配 devicepixelratio 及处理上下文暂停状态。
Web Audio API 的 analyserNode 是最直接的波形数据来源
浏览器里想拿到音频的实时幅度或频谱数据，绕不开 Web Audio API。它不依赖第三方库，原生支持，且能精确控制采样时机。关键在于把音频源连接到 analyserNode，再用 getByteTimeDomainData()（时域，画波形）或 getByteFrequencyData()（频域，画频谱）读取数据。
常见错误是漏掉 analyserNode.fftSize 设置——默认值是 2048，但波形图通常只需 256 或 512 点就足够平滑；设太大反而浪费内存、拖慢 requestAnimationFrame 循环。另外，analyserNode 必须显式连接到音频图中，哪怕只是连到 destination 之前的一个“空节点”，否则数据始终为 0。
-
analyserNode.smoothingTimeConstant控制响应速度：0.8 是默认值，适合音乐频谱；波形图建议设为 0～0.2，让线条更贴合瞬时变化 - 调用
getByteTimeDomainData()前必须传入一个Uint8Array，长度要和analyserNode.fftSize一致，否则报错InvalidAccessError - 音频需用户手势触发（如 click）后才能播放并启用分析，自动播放策略下
analyserNode不会输出有效数据
Canvas 绘制波形比 SVG 更适合高频重绘
每秒 30～60 次更新波形线，Canvas 的 clearRect() + beginPath() + lineTo() 流程比 SVG 的 DOM 节点增删快得多。SVG 在少量静态图形上优势明显，但实时音频可视化本质是像素级连续写入，Canvas 是事实标准。
容易忽略的是抗锯齿和线宽：Chrome/Firefox 默认开启 Canvas 抗锯齿，导致细波形线发虚；加一句 ctx.imageSmoothingEnabled = false 可提升锐度。另外，用 ctx.lineWidth = 1 画单像素线比默认 2px 更省性能，尤其在移动端。
- 避免在每次动画帧里重复创建
Uint8Array，应复用同一实例（例如在初始化时声明const waveData = new Uint8Array(analyser.fftSize)） - 不要用
fillRect()逐个画柱状波形——那是频谱图做法；波形图应使用stroke()连线，起点从左到右依次映射数组索引 - 移动端注意
devicePixelRatio：Canvas 的width/height属性需乘以该值再设 canvas.style.width，否则波形模糊
AudioContext 暂停/恢复时 analyserNode 数据会卡住
当用户切换标签页、播放器被系统休眠，或手动调用 audioContext.suspend()，analyserNode 的数据输出会冻结在暂停前一刻，而不是归零或停止更新。这不是 bug，而是规范行为——AudioContext 暂停后所有处理节点都停止调度。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
真实场景中，这会导致波形“定格”在某个峰值，UI 显得异常。解决办法不是强行重连节点，而是监听 visibilitychange 和 audioContext.onstatechange，在 audioContext.state === 'running' 时才执行数据读取与绘制逻辑。
- 不要在
requestAnimationFrame回调里无条件调用analyser.getByteTimeDomainData()，先检查audioContext.state !== 'running'就直接 return - 恢复播放后，首次绘制前可调用一次
analyser.update()（虽然无此方法），实际应靠重新触发requestAnimationFrame自动同步，无需额外操作 - 若用
MediaElementAudioSourceNode（比如audio标签），注意其currentTime可能因缓冲滞后，波形位置和实际播放点不一致——这是媒体元素自身限制，无法靠 analyser 修正
简单波形图不需要 createScriptProcessor() 或第三方库
ScriptProcessorNode 已被废弃多年，现代代码必须用 AudioWorklet 替代，但对基础波形图而言，完全没必要引入复杂度。95% 的需求用 analyserNode + Canvas 就够了，轻量、可控、调试方便。
第三方库如 wavesurfer.js 适合需要预渲染整首歌波形图（即“静态缩略图”）的场景，但它内部仍是用 OfflineAudioContext 预处理，和实时波形是两套逻辑。混用容易引发时间戳错乱、内存泄漏——比如一边用 wavesurfer 加载音频，一边又自己接 analyserNode，两个上下文竞争同一资源。
- 如果只要实时波形，别装
wavesurfer.js；如果只要静态波形图，用它的load()+renderWaveform()即可，不用启动 Web Audio 实时分析 - 自定义波形颜色、渐变、左右声道分离？直接操作 Canvas 的
ctx.strokeStyle和数据分片（如取前半数组画左声道，后半画右声道），比配置库更灵活 - IE11 不支持 Web Audio API，但如今基本可忽略；若真需兼容，只能退化为显示固定动画或禁用可视化
波形可视化的真正难点不在“怎么画”，而在于“什么时候不该画”——状态同步、上下文生命周期、用户交互时机，这些边界条件比算法本身更容易出问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
