Web Audio API 的 AnalyserNode 是唯一可靠获取麦克风实时音量的方案，需通过 createMediaStreamSource() 接入麦克风流，设置 fftSize 并连接 destination，用 getByteTimeDomainData() 计算 RMS 响度值。
Web Audio API 的 analyserNode 是唯一可靠方案
浏览器不提供直接读取“麦克风音量数值”的 API，navigator.mediaDevices.getUserMedia() 只能打开设备，无法返回实时响度。真正能拿到音量大小（即频域/时域能量）的，只有 Web Audio API 中的 AnalyserNode —— 它把音频流转成可分析的字节或浮点数据，再通过 getByteFrequencyData() 或 getByteTimeDomainData() 提取幅度信息。
必须用 createMediaStreamSource() 接麦克风流
常见错误是试图把 MediaStream 直接塞进 AudioContext，但这是非法操作。正确链路是：getUserMedia → 获取 MediaStream → 用 audioContext.createMediaStreamSource(stream) 转成音频源节点 → 再连到 analyserNode。
关键点：
-
analyserNode必须显式设置fftSize（如128或256），否则getByteTimeDomainData()返回全 0 - 不能省略
analyserNode.connect(audioContext.destination)（即使你不想播放声音）—— 某些浏览器（如 Safari）会静音或中断分析，除非有有效输出路径 - 采样率由硬件决定，
analyserNode不改变它；想降低计算开销，可在 JS 层做降频采样（比如每 50ms 取一次最大值）
getByteTimeDomainData() 比 getByteFrequencyData() 更适合音量检测
音量本质是信号幅度的瞬时变化，不是频率分布。getByteTimeDomainData() 返回的是波形采样点（0–255 映射自 -1.0～+1.0），取其中最大值或 RMS 值即可代表当前“响度”。而 getByteFrequencyData() 是频谱，对人耳感知的音量参考性弱，且计算更重。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 用
new Uint8Array(analyser.frequencyBinCount)初始化缓冲区，传给getByteTimeDomainData() - RMS 计算比单纯取
max()更稳定：对每个值减去 128（还原为有符号），平方、求均、开方，再映射回 0–100 范围 - 避免在
requestAnimationFrame里高频调用——getByteTimeDomainData()是同步阻塞操作，每秒 30 次足够，太高反而卡主线程
权限、静音和空流是三大静默失败原因
代码跑通但 analyser 数据始终为 0？大概率不是逻辑错，而是：
- 用户点了“拒绝”或浏览器自动屏蔽了麦克风（Chrome 在非 HTTPS 页面禁用
getUserMedia）；检查console是否有NotAllowedError或SecurityError - 系统级静音或输入设备被其他应用占用（如 Zoom 正在用麦克风），此时
MediaStream仍能创建，但音频轨道实际无声 -
stream.getAudioTracks()[0]存在但track.enabled === false，需手动设为true，或监听track.onmute事件
最简单的验证方式：把 analyser 连到 destination 后，用耳机听是否有底噪——没声音，说明流本身就没数据进来。
