杂音源于硬件、驱动或配置问题，非HTML/JS所致；常见原因包括麦克风硬件异常、系统驱动设置不当、采样率不匹配及应用独占音频；Web Audio爆音多因节点连接状态异常；需通过系统录音、波形分析及浏览器统计验证。
HTML 本身没有“函数运行时麦克风杂音”这回事——杂音从来不是 getUserMedia() 或 MediaRecorder 产生的，而是音频采集链路中某处引入的干扰或失真。
为什么 getUserMedia() 调用后录音有杂音？
这个现象常被误认为是 JavaScript API 的问题，实际它只是“打开麦克风”的开关，不参与音频信号处理。杂音一定发生在以下任一环节：
- 麦克风硬件本身（如 USB 麦克风供电不稳、3.5mm 插孔接触不良）
- 系统音频驱动未正确配置（Windows 上 Realtek 声卡默认启用“噪音抑制”反而引入爆音）
- 浏览器音频上下文采样率与设备不匹配（例如 Chrome 强制使用 48kHz，但麦克风只稳定支持 44.1kHz）
- 其他应用正在独占音频输入（如 Teams 后台常驻、OBS 开启监听）
验证方法：用系统自带录音机（非浏览器）录同一段声音，若仍有杂音，则与 HTML/JS 完全无关。
Chrome/Firefox 中 MediaStreamAudioSourceNode 引发爆音的常见原因
当用 Web Audio API 接入麦克风流做实时处理（如降噪、增益），MediaStreamAudioSourceNode 一旦连接失败或重连不干净，极易触发瞬态爆音。这不是 bug，而是音频图状态不同步的表现：
- 未在
audioContext.resume()后再连接节点（移动端尤其严格） - 重复调用
connect()同一目标，导致多个音频路径叠加相位抵消 - 使用
createMediaStreamSource()时传入已关闭的 stream（stream.active === false） - Firefox 对
MediaStreamAudioSourceNode的 channel count 处理更敏感，若麦克风是单声道但代码假设 stereo，会插值出异常波形
简单防护：
if (stream.active && audioContext.state !== 'suspended') {
const source = audioContext.createMediaStreamSource(stream);
source.connect(analyser);
}
WebRTC 音频模块兼容性测试该测什么？
别只盯着“能不能拿到 stream”，重点验证音频数据流是否干净、低延迟、可预测：
- 用
MediaRecorder录制 5 秒，导出为 WAV，用 Audacity 查看波形是否截幅（clip）、底噪是否突变、是否有周期性毛刺（疑似电源干扰） - 对比不同浏览器下
RTCPeerConnection.getStats()中的audioInputLevel和echoReturnLoss数值差异（Chrome 通常比 Safari 更激进地启用回声消除） - 在 macOS + Chrome 下测试外接 USB 麦克风时，检查
navigator.mediaDevices.getSupportedConstraints()是否返回noiseSuppression: true—— 若返回false，说明底层驱动未暴露该能力，JS 层强行设{ noiseSuppression: true }会被静默忽略
真实案例：某会议 SDK 在 Edge 下无杂音，Chrome 下高频嘶嘶声，最终发现是 Chrome 90+ 默认启用 autoGainControl 导致 AGC 算法与硬件 ADC 增益冲突，关闭后即恢复。
真正难排查的是软硬交界处的隐性约束：比如某款 Type-C 转接头把麦克风信号误判为耳机麦克风，强制套用错误的增益曲线；又比如 Linux 上 PulseAudio 的 module-udev-detect 加载顺序错乱，导致 ALSA 设备名映射偏移。这些不会报错，只表现为持续的底噪或间歇性破音——得靠 arecord -l 和浏览器 about://webrtc-internals 对照着看。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
