火狐浏览器中用WebRTC调用getDisplayMedia进行屏幕共享时，明明勾选了“共享音频”，但参会者始终听不到系统播放的视频、音乐等声音。这个问题其实挺常见的。

很多人第一反应是“重试一下”，但往往无济于事。

问题的根子，出在权限传递与API行为差异上。

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

先从最基础的问题说起：火狐从91版本才开始正式支持getDisplayMedia捕获系统音频（也就是audio: true）。

如果你的浏览器版本是90.x甚至更低，那代码写得再完美也没用。

打开地址栏，输入 about:support，看看“应用程序版本”字段。如果显示的是90.x或更低，升级是第一步。

旧版火狐会静默忽略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('音频轨道正常')

这段实时反馈比界面上那个勾选框靠得住。

《夸克》非常好用的免费AI浏览器

下载APP查看