先确认麦克风和摄像头权限——Loxinity 首次通话前先过这一关

页面打开了却没有声音或画面，先不要急着重装浏览器或换电脑。Loxinity 首次通话拿不到麦克风和摄像头，通常卡在三层中的某一层：浏览器记住了对这一个站点的拒绝、操作系统没有给浏览器应用设备访问权、设备被别的软件占着。按“浏览器站点权限 → 系统隐私开关 → 设备占用 → 最小代码验证 → 换环境对照”的顺序逐层确认，可以避免在错误的方向上反复调设置。

先看地址栏的站点权限图标，确认 Loxinity 这一站的麦克风和摄像头没有被记住为“阻止”；再进系统隐私设置，确认浏览器应用有麦克风和摄像头访问权；最后排除会议软件、录屏工具对设备的独占。三层都通过后仍失败，用 getUserMedia 最小代码单独请求音频和视频，把页面问题和设备问题分开。任何一层改动后都建议刷新页面重试，并以刷新后的行为作为判断依据。

在站点设置里看这一站的麦克风与摄像头是否被记住为拒绝

浏览器层最容易被忽略的情况是“一次性拒绝被记住”。首次进入通话页时弹窗问是否允许使用麦克风，如果当时点了阻止，浏览器会把这个决定记到站点上，之后不再弹窗，页面直接表现为没有声音或没有画面。

入口位置：Chrome、Edge 在地址栏左侧的权限图标（锁形或调节图标），点开后能看到“摄像头”“麦克风”两个下拉项；Firefox 在地址栏左侧的权限图标，点开后有“已阻止”提示和解除入口；Safari 在菜单栏 Safari → 对此网站的设置，或在系统“设置 → 网站”里按站点查看。
恢复方式：把下拉项从“阻止”改成“允许”，或点“重置权限”让浏览器重新询问。Chrome 也可在 chrome://settings/content/camera 和 chrome://settings/content/microphone 的“不允许使用”列表里找到该站点并删除。
是否要刷新：改完权限后，当前页面通常不会自动重新申请设备，建议刷新页面再点一次开始通话；如果页面把权限状态缓存在内存里，刷新是让改动生效最省事的动作。

还需要留意通话页是否嵌在 iframe 里。嵌在内嵌框架中的页面，申请的是内嵌站点来源的权限，只给外层站点放行不一定够，可以在地址栏图标里确认实际请求权限的来源域名。

到系统隐私设置里确认应用有设备访问权

浏览器层的“允许”只是第一道门，第二道门在操作系统。系统侧没开开关时，浏览器拿到的往往是直接失败，页面甚至不弹权限询问，看起来就像“什么都没发生”。

Windows 上打开“设置 → 隐私和安全性 → 麦克风/摄像头”，需要确认两处：一是“允许应用访问你的麦克风/摄像头”的总开关，二是“允许桌面应用访问你的麦克风/摄像头”。浏览器一般被归在桌面应用这一类，只开上面一项而关掉下面一项，仍然拿不到设备。macOS 上打开“系统设置 → 隐私与安全性 → 麦克风/摄像头”，按应用逐个授权，找到浏览器并勾选，勾选后系统可能提示需要退出应用才能生效。

两种系统的入口差异在描述上很明显：Windows 是“按权限类别找开关”，macOS 是“按应用找勾选框”。开关改动后，建议完全退出浏览器进程再启动，而不是只关闭窗口；macOS 上部分权限项还要求重启应用才被识别。改完重启浏览器，再回 Loxinity 页面重新进入通话，观察是否弹出系统或浏览器的权限询问。

检查设备是否被会议软件或录屏工具占用

权限全部给足仍然失败，就要考虑设备被独占。摄像头和麦克风在多数系统上同一时间只允许一个进程占用，占用方不释放，后来者会直接报错。

常见占用来源：Zoom、Teams、腾讯会议、飞书、钉钉等会议客户端；OBS、系统自带录屏、直播推流工具；另一个浏览器标签页里开着的通话；后台驻留的语音助手或虚拟摄像头驱动。
排查动作：把这些软件彻底退出，注意不是最小化到托盘。Windows 在任务栏托盘右键退出，macOS 用菜单栏退出或访达强制退出；Linux 可用 lsof /dev/video0 或 fuser -v /dev/video0 查看占用进程。
报错表现：这类情况在浏览器里通常表现为 NotReadableError，旧实现里也可能出现 TrackStartError，提示信息多为“Could not start video source”或设备无法启动；音频侧有时是静默失败，录音轨建立后一直没有数据。
验证方法：关闭占用软件后不要直接点重试按钮，建议刷新页面重新进入通话，让页面重新申请一次设备，避免旧的失败句柄影响判断。

用 getUserMedia 的最小代码骨架验证设备可用性

三层都确认过还是不行，就需要把“Loxinity 页面出问题”和“设备本身不可用”分开。方法是在该站点的控制台里直接调用 getUserMedia，绕开业务代码。

(async () => {
  try {
    const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
    stream.getTracks().forEach(t => {
      console.log('OK', t.kind, 'label=', t.label, 'state=', t.readyState);
    });
    console.log('video settings', stream.getVideoTracks()[0]?.getSettings());
    console.log('audio settings', stream.getAudioTracks()[0]?.getSettings());
    stream.getTracks().forEach(t => t.stop());
  } catch (err) {
    console.error('FAIL', err.name, err.message);
  }
})();

运行注意事项：必须在 Loxinity 页面本身的控制台里执行，不要在空白新标签页的上下文里跑，否则测的是另一个来源的权限；页面需要是 https 或 localhost，普通 http 下 navigator.mediaDevices 可能直接不存在。建议先跑音视频一起请求的版本，失败后再分别只请求 { audio: true } 和 { video: true }，定位是哪一路设备出的问题。

成功时看三样：是否打印出 OK、每个 track 的 label 是否是你预期的设备名、getSettings() 里是否给出了合理的分辨率与采样参数。失败时看 err.name：NotAllowedError 指向权限被拒，回前两节排查；NotFoundError 指向系统里没有可用设备或设备未被识别；NotReadableError 指向占用或驱动异常，回上一节排查。

换一台设备和换一个浏览器各测一次并记录差异

最后一步是确认问题跟着账号走还是跟着环境走。做两张对照，把变量尽量固定：网络条件保持一致，最好用同一副耳机或同一个外接摄像头，选择同一时段测试，登录同一账号，每次只改一个因素。

对照表字段建议两列并排：环境（设备型号 / 浏览器及版本 / 系统版本）为一列，观察结果为另一列；观察结果里再细分四项——浏览器站点权限状态、系统隐私开关状态、getUserMedia 输出（OK 或 err.name）、页面实际表现（有无画面、有无声音）。
换浏览器的意义：区分是某个浏览器的权限策略或实现差异，还是设备与系统层面的问题。同一台机器上换浏览器仍失败，倾向系统或设备侧；换浏览器成功，倾向原浏览器的站点权限或配置。
换设备的意义：区分是这台机器的设备与驱动问题，还是账号侧或页面侧的问题。同一浏览器换机器成功，倾向原机器环境；两台机器都失败，才值得把怀疑放到页面或账号配置上。

写结论时不要过度归因。可以表述为“在 A 设备上失败、B 设备上成功，且两个环境的浏览器权限与系统开关状态一致，倾向于 A 设备的设备或驱动侧问题”，而不是直接断言某个软件有缺陷。单次对照只能说明现象出现在哪个环境，不能证明根因；把每次测试的时间、环境、错误名记下来，再带着这份记录去反馈，比一句“用不了”更有助于定位。