Roxi先问清是谁听不到、谁看到卡顿
本文适用于电脑端会议。记录会议软件版本、故障时间、网络连接方式，以及问题发生在声音、摄像头还是屏幕共享。请知情参与者协助确认方向，避免在正式会议中反复打断他人。
| 现象 | 优先观察 |
|---|---|
| 别人说你的声音断续 | 本端音频发送与对方接收；同时确认麦克风输入本身正常 |
| 你听所有人都断续 | 本端音频接收及本地音频设备 |
| 只有一个人的画面卡 | 该路视频及双方差异，不能直接判定全网故障 |
| 本地鼠标、窗口也卡 | 系统 CPU、内存和正在运行的程序 |
| 仅屏幕共享卡住 | 共享的发送／接收方向与共享时的设备负载 |
Zoom：打开 Statistics 看故障当时的数据
桌面客户端可从设置进入 Statistics；会议中也可从视频按钮旁的箭头进入视频设置后查看统计。记录 Overall 里的系统和 Zoom 负载，再按 Audio、Video 或 Screen Sharing 查看对应媒体。菜单随版本不同，找不到时标记未检查，不填“正常”。
发送和接收应分别记录。共享屏幕时，如果你是发送者，接收列可能为空；观看共享时发送列可能为空。空白表示该方向未提供数据，不能抄成零丢包。界面中的当前带宽也不是家庭宽带套餐的测速结果。
Teams：在会议中打开 Call health
从会议的更多操作进入 Settings → Call health，查看网络、音频、屏幕共享及视频统计。官方说明页面约每 15 秒刷新一次；应在卡顿前后连续观察，而不是只截到恢复后的一个数值。
往返时间的测量对象因通话类型而异：群组会议通常到 Teams 服务，一对一通话则可能到另一参与者。因此不要把它直接与 Zoom 或独立测速站的数字横向排名。
用一项改动验证一个猜测
| 观察到的组合 | 下一次可逆对照 | 如何解读 |
|---|---|---|
| 系统负载高，本地操作也卡 | 保存工作后关闭一个高负载程序，再重复原会议动作 | 恢复说明负载可能有关，不能由 CPU 高直接推断网络正常 |
| 媒体出现丢包或抖动，系统负载不高 | 保持设备不变，暂停本人发起的大传输或改用可用有线连接 | 记录故障与统计是否同时改善 |
| 只有共享时出问题 | 停止再恢复同一共享内容，比较共享前后负载与媒体状态 | 先缩小到共享环节，不直接重装音频驱动 |
| 本端发送稳定，对方仍收不到 | 请另一位知情参与者对照接收情况 | 需要双方证据，单端统计不足以定位 |
个人代理或 VPN 是否影响会议，需要保持相同会话场景做对照；受管理连接由管理员处理。不要在正式会议中切换整套网络设置。一次测速正常也不能排除故障时段的瞬时丢包或设备问题。
会议验收和失败记录
- 在相同设备、音频输出和网络下复测原来出问题的媒体：声音做双向说话，视频确认动态画面，共享确认对方能看到操作变化。
- 覆盖原来容易触发卡顿的动作，并记录当时统计和对方反馈。若只验证了音频，不把结果扩展成屏幕共享也通过。
- 恢复临时暂停的程序或连接设置，每次复测，保留确认有效的调整。
- 仍失败时提供时间范围、媒体方向、设备版本和脱敏统计。会议链接、参会人名单及共享内容不要公开贴出。