火狐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('音频轨道正常')，真实反馈比界面勾选更可信。
