性能瓶颈源于实现方式与数据量级，非API本身：需合理设置fftSize=2048、下采样绘制、优化clearRect范围、避免高频路径重绘，并权衡前后端计算与传输开销。
会拖慢，但不是波形本身的问题，而是你选择的实现方式和数据量级决定的。
getByteTimeDomainData() 每帧读 1024 字节也卡？
很多人以为“只画波形不画频谱”，就一定轻量，结果发现 analyser.getByteTimeDomainData() 每帧读一次 Uint8Array（默认长度 1024），Canvas 逐像素描点，帧率立刻掉到 30fps 以下。这不是 API 慢，是计算+绘制没做裁剪。
- 浏览器每调用一次
getByteTimeDomainData()，Web Audio 就要从当前音频缓冲区拷贝原始时域样本（已解码 PCM），再做归一化映射到 0–255 —— 这步开销固定，但频率太高就吃 CPU -
frequencyBinCount和fftSize不影响时域数据长度，但很多人误设了大fftSize=4096，导致 analyser 内部处理变重（即使你没调getByteFrequencyData） - 真实项目中，
getByteTimeDomainData()推荐配fftSize = 2048（对应timeDomainData.length = 2048），再取中间 512 点做下采样绘制，比全画快 3 倍以上
Canvas 绘制波形时 clearRect() 调用位置不对
常见错误是在 requestAnimationFrame 循环里先 ctx.clearRect(0, 0, width, height) 清全屏，再画新波形 —— 这会让 GPU 反复刷整个帧缓冲区，尤其在高 DPI 屏幕上更明显。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 正确做法：只清波形所在区域，比如
ctx.clearRect(0, centerY - 100, width, 200)，其余背景复用上一帧 - 如果波形是左右滚动式（如录音机风格），直接用
ctx.drawImage(canvas, 1, 0, width-1, height, 0, 0, width-1, height)位移旧图，再画最右侧一列，性能提升显著 - 避免在循环里反复调用
ctx.beginPath()+ctx.moveTo()+ 大量ctx.lineTo()；改用putImageData()预生成像素数组，或用createPath2D()缓存路径对象
后端预生成波形数据反而更卡？
有些方案让 Python 后端提前算好波形点（如 wave[::100].tolist()），前端 fetch 后用 Canvas 折线绘制。听起来省事，但实际容易翻车。
立即学习“前端免费学习笔记（深入）”；
- 问题不在“生成”，而在“传输”：一个 3 分钟语音，即使每 100 样本取一点，仍有约 8000 个浮点数 → JSON 体积超 100KB，首屏渲染要等网络+parse+gc，比实时分析还慢
- 若后端返回的是未压缩的
float32数组（非 base64 或 typed array binary），前端还得JSON.parse()再new Float32Array()转换，多一次内存拷贝 - 真正高效的做法：后端只返回关键帧摘要（如每秒峰值、RMS、过零率），前端用插值补形；或返回 WebAssembly 编译的轻量解码器，在本地快速抽样（如 ffmpeg.wasm 的
decodeAudioData+ 自定义 downsample）
最容易被忽略的一点：波形可视化是否真需要毫秒级精度？多数 UI 场景只要 20–30fps 更新率就够了，强行追求 60fps 波形跳动，反而掩盖了音频内容本身——比如语音停顿、语调起伏这些真正该被“看见”的信息。
