Google Meet 没有声音：先确定缺失的音频通路

为什么无声的方向很重要

修改任何设置之前，先用一句话写清楚谁听不到什么。例如：你听不到任何参会者；除了某一个人，其他人都能听到你；或者交谈正常，但演示的视频没有声音。每一种描述都能缩小通路范围。仅凭“没有声音”就重装浏览器并不合理，尤其当输入问题被误认为扬声器问题时。

收到的会议音频经过会议应用、浏览器、选中的输出以及实体扬声器或耳机。发出的语音从你的麦克风开始，经过采集权限和通话。演示音频可能通过另一条独立通路共享。一条通路测试成功，不会自动证明另一条也正常。例如，麦克风指示在变化，并不能说明耳机是否正在收到对方的声音。

MeterSee 提供本地听音基线，而不是 Google Meet 认证。扬声器测试生成简短音调，并请你确认听到了什么。它不能进入会议、听取远端参会者、检查组织策略，或保证真实通话正常。用它区分本地输出问题与仅在 Meet 中出现的症状，然后回到征得同意的会议对比中。

在不打扰会议的前提下准备

1. 如果会议已经开始，通过聊天告诉主持人你正在检查音频。不要让测试音调进入未静音的麦克风。本地测试前先静音或短暂退出；会议重要时，安排另一种沟通方式。不要让同一房间内多台已加入会议的设备同时发声，否则会产生另一种回声问题。
2. 记下打算使用的麦克风和输出设备。通过 HDMI 连接的显示器、USB 扩展坞、蓝牙耳麦和内置扬声器，都可能出现在同一个菜单中。识别实际设备名称，不要假设默认条目就是你佩戴的设备。记录声音消失前刚连接的任何线缆或扩展坞。
3. 首次测试前降低听音音量，然后调整到适合普通语音的舒适水平。检查耳麦实体静音开关和功放电源控制，但不要改动无关设置。条件允许时准备耳机，以免输出测试成功后声音又进入麦克风形成反馈。
4. 重启浏览器前保存工作，并确认你知道如何重新加入会议。即使标签页之后重新打开，重启浏览器仍可能中断上传、表单和未保存的工作。在受管理的工作或学校设备上，不要为完成测试而绕过策略控制或删除必需的安全软件。
5. 每次只安排一种对比。更换应用时保持输出不变，或更换输出时保持应用不变。记录改了什么以及发生了什么。同时切换设备、授予权限、重新加入和更新，虽然可能恢复音频，却会让你无法知道哪个改动起了作用。

排除本来就不提供音频的会议模式

检查加入方式。Google 说明，伙伴模式（Companion mode）不提供普通的麦克风和扬声器通路。当用户主要为了在会议室系统旁演示而加入，却希望笔记本像第二个普通通话端一样工作时，这一点很重要。如果需要这台设备承担交谈，退出该模式并正常加入，同时与会议室协调，只保留预期的音频端点处于活动状态。

麦克风按钮显示静音，不等于收到的声音被静音。点击麦克风影响的是你发送的声音，不决定你是否听到其他参会者。同样，能看到演示内容也不能证明你已经通过普通交谈音频加入。把不可用的麦克风或扬声器视为硬件故障之前，先查看当前会议模式和控制项。

询问至少另一名参会者能否听到当前发言者。如果除了你之外所有人都听得到，检查你的接收通路。如果没人听到发言者，但发言者能听到其他人，应由发言者检查自己的麦克风。如果只有两个人之间报告问题，先请另一名同意协助的参会者比较，再判断任何一方的设备是否故障。测试保持简短，未经许可不要录音。

在 Meet 之外测试本地输出

离开实时交谈环境后，打开 MeterSee 扬声器测试，以低音量播放一个声道。预期结果是从指定设备和对应一侧听到音调。记下首次观察，再播放另一声道。只有左右声道都已播放且播放已经停止后，页面才显示立体声确认；只听到一个音调并不算完成。如果浏览器报告无法开始音频，应把浏览器音频可用性与输出路由分开检查。

如果音调无声，在另一款应用中通过相同的所选输出，播放熟悉的本地音频。两处都无声，会使更广泛的输出、音量、线缆或设备问题更值得怀疑。另一款应用有声而浏览器无声，则应关注浏览器或单应用路由。这两种结果都不要求立刻更改麦克风权限，因为听音与采集语音是独立操作。

如果 MeterSee 有声而 Meet 无声，重新打开 Meet 音频设置，检查扬声器选择。会议开始后连接的设备，可能不是会议当前正在使用的设备。如果界面提供扬声器测试，以相同的舒适音量使用它。如果你的浏览器或设备没有扬声器选择器，核实操作系统输出，并查阅当前客户端对应的控制说明。

通过浏览器常规标签页菜单，检查 Meet 标签页或网站是否被静音。还要查看操作系统提供的单应用音量混合器。即使系统主音量不低，某个应用仍可能无声。不要把所有滑块拉到最大；建立合理听音音量，并确认该浏览器没有静音，也没有被路由到未使用的输出。

接收通路的操作系统检查

在 Windows 11 中，从“设置”→“系统”→“声音”开始。检查所选“输出”设备，必要时进入“音量混合器”，查看浏览器的音量和目标设备。具体控制取决于 Windows 内部版本和音频驱动。较旧的 Windows 安装可能显示传统对话框。菜单不同应促使你查阅已安装版本的帮助，而不是据此判断音频设备不存在。

较新的 macOS 中，“系统设置”→“声音”→“输出”显示可用目标；旧版本使用“系统偏好设置”。明确选择设备并检查可用的音量控制；某些外接输出需要在硬件上调整音量。能够接收音频的显示器也可能列在其中，即使你并不打算通过它听音。选择输出后重新检查 Meet，因为应用自己的选择仍可能不同。

在手机和平板上，使用会议提供的音频路由控制，以及操作系统的已连接设备控制。名称随移动应用、平台和版本而变化。检查声音是否被送往其他地方的蓝牙设备，或送往听筒而不是扬声器。本指南不假设桌面浏览器菜单也存在于移动 Meet 应用中。界面不同时，请在 Google 帮助中选择相应的平台页签。

如果麦克风启用时蓝牙输出消失或变化，在同一会议中比较有线或内置输出。记录问题是完全无声、听音质量下降，还是音源切换；这些是不同的症状。必要时为会议保留稳定的替代输出，之后再排查耳麦通路，不要在演示期间反复重新连接。

别人听不到你时

如果收到的语音正常，但你的声音传不到别人那里，打开 Meet 的麦克风选择并选中预期输入。正常说话，在当前界面提供时观察本地活动指示。指示没有变化，支持继续检查采集与静音状态；指示有变化，表示某种信号到达了这个环节，并不代表远端收到了清晰语音。请另一名参会者做简短口头确认。

检查麦克风实体静音控制、会议静音控制，以及浏览器为 Meet 网站设置的权限。Chrome 的地址栏网站控制中提供权限，但图标外观会随时间变化。只向你打算使用的会议网站授予访问权。拒绝权限涉及访问，而不是麦克风振膜或拾音单元的健康，因此不要把它当成购买替换硬件的理由。

操作系统隐私设置是另一层。Windows 11 的麦克风权限位于“设置”→“隐私和安全性”→“麦克风”，其中包括与桌面应用相关的控制。macOS 使用“系统设置”→“隐私与安全性”→“麦克风”管理应用访问。措辞随版本和管理策略变化。如果设置由管理员控制，应联系管理员，不要试图覆盖组织限制。

必要时将 MeterSee 麦克风测试作为独立的采集对比。选择预期麦克风，允许该网站访问，简短说话后停止。当前工具在本地分析浏览器传来的采样；它不是录音工具，也不是 Meet 传输测试。那里电平有变化，支持该浏览器环境中的采集能够工作。它不会把权限转移给 Meet，也不能证明 Meet 选中了哪个设备。

只有演示内容无声时

先确认普通交谈在两个方向都正常。如果正常，保持这些已工作的设备不变，检查演示通路。共享可见窗口本身，并不能证明其声音也被共享。在共享选择器中，检查所选标签页、窗口或屏幕实际提供的音频选项。播放简短且不含隐私的样本前，确认选中了预期音源。

Google 当前的桌面演示说明包含标签页音频共享，并在受支持时提供随窗口或整个屏幕一起包含系统音频的选项。是否可用取决于浏览器、操作系统、会议情境和功能推出情况。不要依赖“所有桌面演示都必须只共享标签页”这样的旧式一概而论，也不要假设每台设备都有系统音频共享。如果没有系统选项，仍可能有受支持的标签页音频流程。

系统音频共享可能暴露通知声和其他应用的音频。启用之前，关闭私人媒体并静音不必要的通知。优先选择满足演示需要的最小共享范围。请一名参会者确认简短样本，然后停止播放。他们的确认说明所选演示通路在当时有效，不代表电脑上每款应用都会以完全相同的方式共享。

如果主持人或组织禁用了共享，修改耳机或麦克风设置并不能解除该限制。同样，移动应用的共享能力可能不同于桌面浏览器。查阅当前平台专属的演示帮助，使用实际显示的控制项。处理演示问题时，应保留已工作的交谈通路，而不是重启所有音频设备。

有目的地使用重启与对比

当路由和权限看起来正确时，退出会议，正常关闭不必要的麦克风使用应用，然后重新加入一次。如果仍然失败，保存工作并按照浏览器说明重启。记录重启后设备列表或权限提示是否变化。会话恢复有用，但仅凭重启不能识别最初原因；如果症状之后再出现，应将它记录为临时恢复。

只有在能够正常登录和加入、且不绕过策略时，才比较第二款受支持的浏览器。保持相同设备和会议，使浏览器环境成为主要变化。第二款浏览器成功，指向某种浏览器特定配置或兼容性差异，并不能证明第一款浏览器本质上不适合。隐私浏览也不保证环境不受管理或完全没有扩展。

不要在重要通话期间执行从通用音频清单复制的终端命令。重启音频服务和修改驱动会中断其他应用，还可能需要管理员权限。如果常规选择、权限检查和计划内重启都未能解决问题，应收集证据交给管理员或支持团队。更深入的改动需要针对设备的说明以及合适的维护时段。

假设案例：没有声音的三种含义

假设案例一：笔记本连接到会议室显示器。MeterSee 音调来自显示器而不是用户的耳麦，Meet 在耳麦中也听不到。选择预期耳麦后，两者都恢复。这些证据支持该配置中存在输出路由错误。它不意味着需要修改麦克风权限，也不能据此对网络质量作出判断。

假设案例二：参会者能清楚听到会议，但自己的活动指示一直不动。允许独立麦克风测试网站访问后，该测试成功，然而 Meet 仍显示麦克风被阻止。专门向 Meet 授予权限并重新加入后，语音恢复。关键区别在于权限属于各个网站；诊断页面成功，并没有授权会议页面。

假设案例三：所有人都能听到演示者说话，但共享窗口中的视频无声。演示者检查共享选择器，发现没有包含音频。他们选择受支持的音频共享通路，一名参会者确认了简短样本。正常交谈通路从来没有损坏。重装音频驱动只会增加风险，无法解决遗漏共享选项的问题。

常见问题与支持交接

本地测试显示绿色，是否说明会议已经就绪？这只表示测量或人工确认的本地检查满足了其明示条件。Meet 有自己的设备选择、权限、通话通路和参会者。最后应在你准备使用的会议里完成真实的双向确认，尤其是在切换扩展坞或耳麦后。不要把生成的音调等同于成功的远程沟通。

应该允许所有网站使用麦克风吗？不应该。只向你需要的特定可信网站和应用授予访问权，并保留其他隐私选择。如果页面因环境不受支持或策略阻止而无法请求采集，应调查该限制。广泛开放权限既没有必要，也不是麦克风正常工作的诊断证据。

如果没有第二台设备，也没有愿意配合测试的人怎么办？完成能够进行的本地检查，并明确标出缺失的比较。你可以确认音调可听见，或浏览器收到了麦克风采样，但远端接收仍未验证。通过会议聊天安排稍后的简短确认，不要把没有执行的通话测试表示为通过。

向支持团队提供平台、浏览器版本、设备名称、会议模式、缺失声音的方向，以及问题出现前的最后一次变化。列出哪些本地和 Meet 测试正常，是否有另一名参会者确认，以及问题仅影响交谈还是演示。截图中移除会议链接、参会者姓名和私人屏幕内容。简洁且针对具体通路的报告，比一串无关的修复尝试更便于处理。