背景

用户反馈在聊天开麦说话，后端没有收到活跃的数据，聊天室是基于Web-RTC实现的，活跃数据是根据RTC的回调获取的，
在RTC后台查询发现确实用户开麦了，但是采集到的音量一直是0，像是用户一直没说话；
分析后发现，这些用户都是使用了前端自定义的录音功能，自定义录音是使用 mediaRecorder 进行了录音，并且这次录音跟Web-RTC使用的麦克风ID 是一样的
相当于 同一时段内存在多路麦克风使用（RTC 一路 + 再 getUserMedia 一路），就是说有两个线程对系统麦克风进行了抢占使用；
在外置声卡 + 厂商驱动的机器上反馈更多，且往往不是必现。

一、常见现象

二、原因怎么理解

浏览器层面

对同一物理设备多次 getUserMedia（含指定 deviceId），一般会得到多条独立轨道，规范上 允许 多路并存，因此不是 「标准禁止双开」 这一句话能解释所有问题。

系统 / 驱动 / 声卡层面（外置声卡上更常见）

1. 路由复杂：厂商驱动里多输入、监听、混音、独占/共享等策略，可能让两路浏览器采集落到 不同逻辑通道 ，出现一路有能量、另一路极低或像静音。
2. 近似独占：部分驱动或机架在特定设置下，第二路句柄能建起来，但实际拿不到有效 PCM。
3. 处理链叠加：若两路都开回声消除、降噪等，对同一声源 重复处理 ，极端情况下某一侧在「音量指示」上长期接近 0。
4. 设备不一致：两路若未对齐同一 deviceId（一路默认、一路指定错），可能一路对真麦、一路对空设备。
5. 为何不全员必现：驱动版本、控制面板选项、是否同时开 DAW/直播软件、USB、系统负载等都会改变行为，所以是概率问题。

三、业务里容易放大问题的写法

• 第二路 getUserMedia 采完不关：MediaStreamTrack 不 stop，会长时间占着第二路消费者，与 RTC 并发时间拉长。
• 切页/切房只停定时器、不释放第二路流：同样会延长双开窗口。
• 排查时混用多条上报或统计口径：容易把「采集为 0」和「请求没发 / 服务端没落库」混在一起，需分开验证。

四、两种前端方案

方案 A：与 WebRTC 使用同一条麦克风轨道

做法：从 RTC 本地音频对象取出已发布的 MediaStreamTrack（具体 API 依 SDK 而定），再 new MediaStream([track]) 交给 MediaRecorder 等，不再为录音单独 getUserMedia。

• 优点：物理上只有一路采集进浏览器管线（就这一条轨），与「双开抢设备 / 双路 DSP」相关的风险最小。
• 代价：录音与推流同生共死——用户关麦、unpublish、重连导致轨失效时，录音也会断；产品上要约束「先开麦再录、录完再关」等，并在 UI 上拦截关麦。

方案 B：保留第二路 getUserMedia，但用完立即释放

做法：业务录音仍单独 getUserMedia，在录音结束、失败或取消时对这一路 stream.getTracks().forEach(t => t.stop())，必要时清空引用。

• 释放之后是否还会影响 WebRTC？
  • 通常不会长期影响：stop() 后第二路消费者结束，不再与 RTC 并发争同一设备；RTC 那一路若仍正常发布，后续音量应能回到「只有一路采集」时的表现。
  • 并发那一段仍可能出问题：只要两路同时存在，上面第二节里的驱动/路由/AEC 叠加风险依然存在；释放解决的是缩短并发窗口、避免占着麦不走，而不是让「曾经双开过的那几秒」在事后改写。
  • 若释放后 RTC 仍异常，更多要怀疑：驱动状态、需重采、或 RTC 轨本身已被其它逻辑 mute/结束等，需单独查。

小结：

• 方案 A从架构上减少双采集，适合能接受到「录音跟麦位强绑定」的产品。
• 方案 B适合必须独立录音链路的场景；及时 stop 能显著减少持续双开带来的问题，但不能等价于「从未双开过」。

五、排查建议

1. 区分：浏览器里是否还有第二路未 stop 的 track（开发者工具里看 chrome://webrtc-internals 或等价手段）。
2. 对比：仅 RTC vs RTC + 第二路同时存在时的音量/波形。
3. 外置声卡用户：记录声卡型号、是否机架、驱动版本，便于复现。

六、关键词

getUserMedia、MediaStreamTrack、WebRTC、多路麦克风、声卡驱动、MediaRecorder、音量指示