如何解决火狐浏览器中使用WebRTC协议进行屏幕共享时没有系统声音的问题

火狐91+版本才支持getDisplayMedia捕获系统音频；需显式传{video:true,audio:true}、运行于HTTPS/localhost；授权被拒需手动重置屏幕共享与麦克风权限；Windows/macOS需检查系统音量设置；SDP中无m=audio或getAudioTracks()为空表明前端调用失败。

火狐浏览器中用WebRTC调用getDisplayMedia进行屏幕共享时，明明勾选了“共享音频”，但参会者始终听不到系统播放的视频、音乐等声音，问题卡在权限传递与API行为差异上，不是简单重试就能解决。

确认火狐是否支持系统音频捕获

火狐浏览器从版本91起才正式支持getDisplayMedia中audio: true捕获系统声音，低于该版本即使代码写对也必然失败。在地址栏输入about:support，查看“应用程序版本”字段，若显示90.x或更低，必须升级到91+版本。

旧版火狐会静默忽略audio: true参数，不报错也不生效——这是最容易被误判为“配置没生效”的根源。

检查getDisplayMedia调用时的约束条件

方法一：显式声明audio为true并启用必要提示

必须使用{ video: true, audio: true }完整对象传参，不能只写{ audio: true }（火狐会因缺少video约束而拒绝请求）。

方法二：避免在非安全上下文（HTTP）下调用

【火狐强制要求getDisplayMedia必须运行在HTTPS或localhost环境下】，HTTP页面直接调用会立刻抛出NotAllowedError，且后续同域名下所有尝试均被浏览器临时封禁，需清空站点数据才能恢复。

排查用户授权环节的隐藏拒绝

第一步：观察地址栏左侧图标

成功触发共享选择器后，若用户点击“取消”或关闭窗口，火狐会将该站点标记为“已拒绝”，此后1小时内再次调用getDisplayMedia将直接reject，不再弹窗。

第二步：手动重置权限

在当前页面地址栏左侧点击锁形图标→“网站设置”→找到“屏幕共享”→将权限从“阻止”改为“允许”；再向下滚动，找到“麦克风”→同样设为“允许”（audio: true依赖麦克风权限链）。

第三步：验证是否触发了系统级静音拦截

Windows用户需打开“音量合成器”，确认firefox.exe进程未被静音且音量滑块未归零；macOS用户需进入“系统设置→声音→输出”，确认默认设备未被切换为“无声”或“蓝牙耳机”等无系统声路由的设备。

服务端与信令层的音频流透传校验

方法一：检查SDP Offer中是否包含audio m-line

在Firefox开发者工具→“网络”标签页中筛选media类型请求，找到发起共享后的第一个offer SDP文本，搜索m=audio字段——若不存在，说明getDisplayMedia返回的MediaStream根本未含音频轨道，问题一定出在前端调用环节。

方法二：监听MediaStream轨道状态

在调用getDisplayMedia后立即插入调试代码：stream.getAudioTracks().length === 0 ? console.warn('音频轨道为空') : console.log('音频轨道正常')，真实反馈比界面勾选更可信。