iPhone 投屏到 Windows，这件事最大的错觉就是"装个软件就完事了"。我前后折腾过不下十套方案，从最早只能靠第三方工具硬凑，到后来把 USB 有线、AirPlay 无线、OBS 采集、推流、虚拟摄像头这几条链路全部打通并串成一套流程，中间踩的坑足够写一本小册子。核心症结其实很朴素：iOS 和 Windows 之间压根没有一条官方铺好的投屏通道，iOS 生态内的屏幕镜像只认自家设备，一旦跨到 Windows，所有能力都得靠外部方案去"补"，而不同的补法在时延、画质、稳定性上差着数量级。这篇内容适合三类人看：需要长期用 iPhone 做演示或录课的人、想把手机画面接进直播或会议工作流的人、以及已经能用但总在关键时刻掉帧花屏、想搞清楚原因的人。我把这五条链路的原理、参数搭配、排查顺序和实操心得分层拆开讲，看完你至少能判断"我这个问题该换链路还是该调参数"。

1. 五条链路并存的真实原因：iPhone 到 Windows 之间没有原生通道

1.1 苹果生态内的投屏为什么一到 Windows 就断档

在 iOS 生态内部做屏幕镜像，链路是端到端闭环的：发送端负责编码，接收端是同一套体系里的设备，协议、时钟、解码能力全部对齐，用户只需要点一下"屏幕镜像"。这套体验的顺滑不是因为技术简单，而是因为两端都在同一家手里，中间不需要做任何兼容性妥协。

跨到 Windows 就完全是另一回事。Windows 侧没有任何系统级组件愿意充当 iOS 屏幕镜像的接收端，这意味着你必须自己在中间搭一个"翻译层"：要么走物理线缆建立数据通道，要么在局域网里模拟一个符合 iOS 发现规则的接收端，要么干脆放弃"投屏"这个概念，把手机画面当成一路视频信号去采集。三种思路对应三种完全不同的工程实现，也就直接导致了多条链路并存的局面。

我见过太多人把这几条链路混为一谈，觉得"反正都能看到手机屏幕"。实际用起来差别巨大：USB 链路在演示现场稳如老狗，AirPlay 在会议室 Wi-Fi 下可能三十秒断一次；OBS 采集灵活到可以随意叠加图层，但你得先接受它多出来的一跳延迟。搞不清楚自己走的是哪条路，排查问题就永远在猜。

还有一点值得说明：这五条链路并不是互相替代的关系，更常见的情况是串联。典型的工作流是"手机 → 某条接入链路 → OBS 编排 → 推流或虚拟摄像头输出"，前面的接入方式决定画质和时延的底子，后面的输出方式决定观众端的观感。把这条流水线想清楚，你才知道瓶颈卡在哪一段。

1.2 五条链路的能力边界对照

下面这张表是我自己在不同场景下反复实测后总结的区间值，不是实验室理论值，会有浮动，但量级关系是可靠的：

看懂这张表的关键不是记数字，而是理解"时延是被谁吃掉的"。USB 链路之所以快，是因为它绕开了无线协商和网络抖动这两个最大变量；AirPlay 之所以慢且不稳，是因为它必须先把画面编码、打包，再穿过共享信道，接收端还要做缓冲对齐；推流之所以最慢，是因为它多了一次编码和一次公网传输。你在哪一段加了多少东西，最后都会体现在观众的感受上。

我个人的经验判断是：如果一场演示超过二十分钟，或者需要精确到"我点这里，你看到这里"的实时互动，直接上有线，别犹豫。如果只是让人看个大概、走走停停地讲，AirPlay 完全够用，省一根线的自由感是值得的。

1.3 从使用目的反推链路，而不是从技术栈反推

新手最容易犯的错是先选工具再想场景，结果拿着一套直播专用的重型配置去做十分钟的会议分享，光启动就要两分钟。我的建议是反过来，先问三个问题：

第一，观众是谁、在哪看。如果观众就在同一个房间看大屏，那你的终点是"显示器"，USB 直连最省事；如果观众在远程，终点就变成"网络流"，OBS 加推流这条路径才成立；如果观众是会议软件另一端的同事，虚拟摄像头是最短路径。

第二，这个画面需不需要被加工。一旦你需要加字幕、加画中画、加鼠标高亮、把手机画面和电脑画面并排放在一起，OBS 这一层就必须插进来，因为它是唯一能对画面做实时编排的环节。不需要加工就直接端到端，多一层就多一份延迟和故障点。

第三，能容忍多长的中断。这个指标常被忽略。有线链路即使出问题，重新插拔一次通常十秒内恢复；无线链路一旦掉连，可能要重新走一遍发现和握手；推流断了，观众端就是黑屏，恢复还得等关键帧。对"绝对不能黑屏"的场合，我会额外准备一条备用链路同时在线，主链路出问题立刻切场景。

把这三个问题答完，链路基本就定死了，剩下的全是参数调优和排错，工作量小得多。

2. USB 有线链路：把不确定性压到最低的那条路

2.1 有线投屏的数据是怎么从手机走到屏幕的

很多人以为 USB 投屏是"把屏幕像素通过线缆搬过去"，实际完全不是。真实过程分成四步：设备通过 USB 建立连接并完成配对授权；桌面端服务向设备请求屏幕画面通道；设备侧用硬件编码器把画面压成视频码流，通常是 H.264 或 HEVC，同时把音频单独编码；桌面端收到码流后解码、缩放、渲染到窗口。

理解这四步的意义在于定位问题。画面糊但流畅，说明编码分辨率或码率给低了；画面清晰但卡顿，多半是解码或渲染跟不上，或者 USB 带宽被挤占；画面完全出不来，问题在第一步的配对授权；画面出来但没声音，是音频通道没建立或者被系统路由到了别处。四条症状对应四个完全不同的环节，一上来就重装软件是最没效率的做法。

另一个常被忽略的点是"缩放发生在哪一侧"。设备原生分辨率往往和你的输出目标不一致，如果缩放放在解码之后由桌面端做，画质损失小但吃 CPU 和 GPU；如果设备侧直接按目标分辨率编码，省资源但可能因为非整数倍缩放产生轻微模糊。我一般优先让设备按接近目标的分辨率输出，避免二次缩放叠加两次采样损失。

2.2 首次连接的准备清单与三个必修项

第一次把 iPhone 接到 Windows 上，有三件事必须做对，否则后面所有调优都是白费：

1. 信任授权。设备插上后会弹出"要信任此电脑吗"，必须点信任并输入锁屏密码。这一步没做，桌面端只能看到设备但拿不到画面通道。如果误点了"不信任"，需要在设备的开发者设置里重置位置与隐私授权，再重新插拔。
2. 线材与接口。这一步坑最多。市面上大量线材只有充电能力没有数据能力，插上去设备在充电，桌面端却什么都看不到。判断方法很简单：插上后看系统设备列表里有没有出现新的移动设备条目，没有就是线的问题。接口方面，优先插主板直出的 USB 3.x 口，不要用前面板延长线或者廉价扩展坞，那些地方的供电和信号质量都不稳。
3. 驱动与后台服务。桌面端通常包含一个常驻后台服务，负责与设备通信。这个服务被杀毒软件拦、被系统省电策略休眠、或者开机没自启，都会表现为"偶尔能连偶尔不能"。我习惯把它加进启动项白名单，并且在电源计划里禁止 USB 选择性暂停。

提示：如果你的机器同时插着多个 USB 设备，尤其是无线接收器类的外设，把投屏用的接口和它们分开。USB 3.x 工作时产生的射频噪声对 2.4G 频段有实际影响，这一点在后面讲无线链路时还会再提。

2.3 分辨率、帧率、码率的搭配逻辑

这三个参数不是随便填的，它们之间有一条简单的约束关系：单位时间内要传的数据量约等于分辨率像素数乘以帧率再乘以每像素比特数，而这个乘积必须落在链路的承载能力之内。USB 链路的承载能力通常很充裕，真正的上限往往在设备侧编码器和桌面端解码器上。

我的常用搭配是这样的：

关于帧率有一点要特别说明：手机屏幕的动画多数是 60 帧的，如果你把投屏帧率锁在 30，快速滑动时会出现明显的"拖影感"，观众会觉得卡，但其实链路一点问题没有。反过来，如果内容本身是静态的 PPT，60 帧纯属浪费资源，还会让设备发热更快。我在长时间演示时一般锁 30 帧，因为手机发热降亮度带来的画质下降，比帧率减半更影响观感。

分辨率这里还有一个细节：iPhone 的屏幕比例不是 16:9，直接投到 1080p 会出现黑边或者被裁切。要么接受黑边，要么在桌面端把画布设成设备比例（比如接近 19.5:9 的自定义尺寸），后者在 OBS 里更好处理，因为你可以直接把来源铺满画布而不用做裁切。

2.4 有线也卡的时候，按这个顺序查

有线链路出问题的概率低，但一旦出问题，症状往往很迷惑。我按照"从物理层往上"的顺序排，效率最高：

先看供电与线材。换一根确认支持数据传输的短线，换一个主板直出口，很多"插上没反应"的问题在这一步就解决了。接着看设备端状态，锁屏状态下部分方案会降低画面刷新甚至暂停推送，把屏幕常亮打开试试。然后是桌面端的解码负载，打开任务管理器看解码时 GPU 的 Video Decode 占用，如果接近满载，说明你的解码器选错了，改成硬件解码或者降低输出分辨率。最后才怀疑软件本身。

还有一个非常隐蔽的坑：手机电量低时的性能策略。设备在低电量模式下会限制编码性能，表现为投屏画面间歇性掉帧，而你去看桌面端的各项指标全都正常。我遇到过好几次，排查了半小时，最后发现是手机剩 15% 电。从那以后我养成习惯，长时间投屏一律插着电，并且把低电量模式关掉。

3. AirPlay 无线链路：画质上限由路由器决定，不由软件决定

3.1 一次无线投屏要经过的四个阶段

AirPlay 的工作过程可以拆成发现、握手、协商、传输四个阶段，每个阶段失败的表现都不一样，认清这一点排查起来会快很多。

发现阶段靠的是局域网内的服务广播，iOS 设备在同一个网段里寻找符合规范的接收端。这一步失败的典型表现是"投屏列表里根本看不到你的电脑"，问题一定在网络层：不在同一网段、路由器开了客户端隔离、防火墙拦了广播、或者虚拟网卡优先级更高把流量劫走了。握手阶段是建立加密连接并交换能力信息，失败表现为"能看到但连不上"或者连上立刻断开。协商阶段双方确定分辨率、帧率、音频格式，这一阶段出问题的表现是画面能出但很糊或者没声音。传输阶段才是真正的数据流动，花屏、卡顿、延迟高都发生在这里。

我之所以强调这个拆分，是因为太多人把所有无线问题都归因于"信号不好"。实际上"列表里看不到设备"和"画面花屏"是两个毫不相干的故障，前者是发现阶段，后者是传输阶段，用同一套方法去修必然无效。

3.2 网络环境的三个隐性指标

决定 AirPlay 体验的从来不是"信号几格"，而是三个更具体的指标：

频段与信道宽度。5G 频段是必须的，2.4G 频段在会议室这种密集环境下基本没法用，因为蓝牙、无线鼠标、微波炉全在抢。但 5G 也不是万能，信道宽度开得太宽（比如 160MHz）在干扰较多的环境反而更容易受打击，我一般固定 80MHz，兼容性和吞吐比较平衡。

同一信道上的设备密度。这个指标你在手机上看不到，得进路由器后台看。一个会议室里十几台设备连同一个接入点，即使每台都不传大流量，空口竞争也会把投屏的抖动放大。有条件的话给投屏设备单独留一个接入点或者一个独立 SSID，效果立竿见影。

上行方向的质量。投屏是设备往外发数据，考验的是上行。很多人只测下载速度，实际上下载 500M 上行只有 20M 的环境，投屏一样会糊。我的经验阈值是上行稳定在 30 Mbps 以上、往返时延抖动控制在 10 毫秒以内，AirPlay 才谈得上"流畅"。

顺带说一个反直觉的现象：把设备和电脑放得很近、中间没有任何遮挡，并不一定更好。距离过近时接收功率过高，某些网卡会自动降功率，反而引起速率波动。我遇到过两次"贴着放就卡、拉开两米就正常"的情况，一开始完全没往这个方向想。

3.3 花屏、音画不同步、频繁掉线的分别归因

这三类症状对应的成因完全不同，分开说。

花屏和马赛克几乎都是丢包导致的。视频码流是压缩过的，丢一个包可能影响一整片宏块，所以表现是一块一块的彩色噪点。解决方向是降低码率和分辨率给链路减压，或者把设备挪到干扰更小的位置。注意区分：如果花屏是"整屏瞬间绿一下又恢复"，那更像是解码器重置，问题在接收端而不在网络。

音画不同步的根源是音频和视频走了两条独立的通道，各自有自己的时间戳。视频因为压缩率高、缓冲深，天生比音频慢一点，接收端需要做对齐。当网络抖动大时，对齐逻辑会不断调整，表现为声音忽前忽后。这种情况调网络比调软件有用，我实测下来把缓冲区固定成一个稍大的值、牺牲一点延迟换取稳定，观感反而更好。

频繁掉线要分两种。一种是固定间隔掉，比如每隔几分钟断一次，这往往是节能策略或者会话超时，检查系统电源管理里有没有允许关闭这个设备省电。另一种是无规律掉，多半是信号覆盖边缘或者接入点负载过高。前者改配置，后者只能改环境。

3.4 无线链路该用和不该用的场合

我把 AirPlay 的适用边界总结成一句话：讲解者需要移动、观众对延迟不敏感、内容以静态或慢速变化为主。三个条件同时满足时，无线的体验是压倒性的好，因为一根线带来的束缚感在讲台上会被放大十倍。

反过来，只要出现下面任何一种情况，我就坚决切有线：需要精确的实时互动（比如观众说"点左上角"，你要立刻响应）；内容包含高帧率动画或游戏画面；现场网络不由你控制且设备密集；演示时长超过半小时且不允许中断。

还有一类场景容易被忽略：录屏。用无线链路录屏，你会在回放时发现画面偶发的细微卡顿和花屏，这些在实时观看时被大脑自动忽略了，但录下来反复看会非常明显。凡是最终要变成文件的，一律走有线。

4. OBS 采集层：把投屏画面变成可编排的素材

4.1 为什么中间要插一层 OBS

如果只是"把手机画面显示在电脑上"，确实不需要 OBS。但只要你的需求里出现下面任何一条，OBS 就成了必需品：需要把手机画面和电脑画面并排展示；需要在画面上叠加文字说明、箭头标注、进度提示；需要录制成文件并同时推给远程观众；需要在多个画面源之间平滑切换。

OBS 的价值在于它把"视频源"和"输出"解耦了。上游可以是投屏窗口、可以是虚拟摄像头、可以是浏览器里播放的接收端页面，下游可以是本地录制、可以是推流、可以是注册成系统摄像头。中间这一层你想怎么编排就怎么编排。这种解耦带来的灵活性，是任何单一投屏工具都给不了的。

代价是多了一跳处理和一份额外的资源占用。我的实测是，1080p30 的采集加编码，在中端独立显卡上大约吃掉 8% 到 15% 的 GPU，CPU 占用取决于编码器选择。这个成本对绝大多数机器是可以接受的，但如果你用的是多年前的低压轻薄本，就要认真考虑是不是真的需要这一层。

4.2 采集源类型的选择与取舍

OBS 里能接投屏画面的方式主要有三种，各有明确的适用条件：

窗口采集是最常用的。它抓取某个应用窗口的内容，优点是可以只抓投屏窗口，不带上桌面上的其他东西，隐私性好；缺点是某些用硬件加速渲染的窗口抓不到，表现为全黑。遇到黑屏先换渲染模式试试，Windows 上通常有两种抓取方式可选，换一种往往就好了。

显示器采集抓整个屏幕。好处是绝对不会黑屏，坏处是你得自己控制别把不该露的东西露出去。我在做单人录课时用它，因为我可以保证桌面上只有该有的东西；做多人协作演示时坚决不用。

视频采集设备用于把虚拟摄像头当作源接入。这条路径看起来绕，但在需要"多个软件共享同一路手机画面"时特别有用——因为摄像头设备是可以被多个程序同时调用的，而窗口采集只能给 OBS 一家用。

还有一种是浏览器源，用于接入基于网页的接收端。这种方式的好处是跨平台、不依赖本地解码器，坏处是多了一层浏览器渲染，延迟和色彩管理都不太可控。我一般只在没有其他选择时用。

4.3 场景编排：多机位、画中画与标注

OBS 真正好用的地方在场景编排。以"手机操作演示加讲解"为例，我的典型配置是三层：底层是电脑桌面，中间层是手机投屏画面缩放到画面右侧约 60% 宽度，顶层是文字标注和鼠标高亮。这样观众既能看到操作结果，也能看到操作过程，还能看到我打的说明。

多机位的做法是把不同的手机或不同的画面来源放进不同场景，用转场切换。这里有个实操细节：转场动画时长建议控制在 150 到 300 毫秒，太短会显得突兀，太长会让观众等待。另外所有场景的画布分辨率必须一致，否则切换时会出现黑边或者拉伸，这个问题在临时搭建时特别容易犯。

标注方面我强烈建议用独立的文本源和图像源，而不是在画面上直接画。原因很实际：直接画的东西无法复用，每次都要重画，而且录完之后想改也改不了。用独立源的话，改个文字内容就行了。

还有一个容易被忽略的编排技巧：给手机画面加一个细边框。投屏画面和桌面背景常常颜色接近，观众分不清哪里是手机、哪里是电脑，加一圈 2 像素的浅色描边，辨识度立刻提升。这个细节在很多专业直播里都能看到。

4.4 OBS 里最容易出现的四类画面问题

全黑。最常见，原因通常是采集方式与渲染方式不匹配，或者源被放到了画布外面。排查顺序是先把源的位置和缩放重置，再换采集方式，最后才怀疑软件版本。

卡顿但帧率显示正常。这种情况我遇到最多的是"GPU 过载"，编码器和游戏抢资源。解决方法是给编码器指定一个独立的硬件单元，或者把编码预设从高质量档降到均衡档。看起来是妥协，实际上观感差别很小。

色彩发灰或者过饱和。这是色彩范围不匹配导致的，投屏链路输出的可能是有限范围，而渲染按完整范围解读，结果就是暗部发灰、亮部发白。解决方式是在来源或输出的色彩设置里把范围对齐。这个问题我在至少三个不同的组合里遇到过，症状一模一样，但每次都要重新确认一遍设置。

画面比例被拉伸。多半是画布比例和源比例不一致，又被强制铺满。永远优先保持源的原始比例，多出来的部分用背景填充，不要拉伸。

5. 两个出口：推流与虚拟摄像头的分工

5.1 推流链路：编码器、协议与码率的三角关系

推流解决的是"画面要送到不在现场的观众面前"。这条链路的三个变量互相牵制，任何一个给得不合适都会出问题。

编码器选择上，能用硬件就不用软件。硬件编码（显卡自带的编码单元）延迟低、占用少，代价是同码率下画质略逊；软件编码画质更好但吃 CPU，在需要同时做别的事情的机器上很容易把系统拖垮。我的判断标准是：如果这台机器只干推流这一件事，用软件编码榨画质；如果还要同时做录制、演示、开会议，老老实实用硬件编码。

协议方面，低延迟场景优先选延迟更低的协议，普通直播场景用最通用的那种就够了，兼容性最好。协议的选择其实没有太多纠结空间，取决于你的接收端支持什么，以及你能接受的延迟量级。

码率是最需要认真算的。经验公式是：码率（Mbps）≈ 分辨率像素数 × 帧率 × 运动系数 ÷ 1000000，其中运动系数静态内容取 0.03 到 0.05，有动画的取 0.08 到 0.12。1080p30 的静态演示，算下来大概 2 到 3 Mbps 就能看，但实际上我给到 5 Mbps，因为压缩算法在细节区域的表现总是不如预期。以下是常用的几档：

关键帧间隔这个参数值得单独说一句。设得太长，观众中途进来要等很久才能出画面；设得太短，码率浪费在重复的完整帧上。2 秒是一个比较稳的默认值，我在所有场景下基本都用它。

5.2 虚拟摄像头：让会议软件把手机画面当成本地摄像头

虚拟摄像头的本质是把 OBS 的输出画面注册成一个系统级的视频设备，这样任何调用摄像头的软件——会议、录课、即时通讯——都能直接选到它，不需要这些软件本身支持投屏。

这条路最大的好处是通用。你不需要关心对方用什么软件、什么版本，只要它能选摄像头，你就能把手机画面送进去。而且因为虚拟摄像头是系统设备，多个软件可以同时调用，这在"一边开会一边录制"的场合非常实用。

配置上有几个必须注意的点。第一，输出分辨率要和会议软件的预期匹配，绝大多数会议软件按 1280×720 或 1920×1080 处理，你给个奇怪的比例会被强行裁切或者加黑边。第二，帧率固定 30 就够了，会议场景 60 帧没有意义，还会增加编码压力。第三，务必在会议软件里手动选择这个虚拟设备，很多软件默认选物理摄像头，你不改它就一直用笔记本自带的那个。

还有一个实操心得：在正式会议前五分钟先自己开一个测试会议看一眼画面。我踩过一次坑，虚拟摄像头注册成功但会议软件拿到的是一帧静止画面，原因是 OBS 的场景里源被静音了——对，视频源也有类似"停用"的状态，从界面上看完全正常，就是不动。

5.3 输出参数的成套配置建议

把前面几节的内容收拢成一套可直接抄的配置。这套参数我在中端笔记本（独立显卡，16G 内存）上跑了很久，覆盖了绝大多数日常需求：

• 画布：1920×1080，30 帧
• 手机画面源：等比缩放到画布高度的 90%，居中偏右
• 编码：硬件编码，预设"均衡"，码率 6 Mbps，关键帧间隔 2 秒
• 录制：与推流使用同一编码器，输出 MP4，质量档略高于推流
• 音频：单独一个音轨，采样率 48kHz，来源为投屏音频和麦克风的混合
• 虚拟摄像头输出：1920×1080，30 帧

需要说明的是，录制和推流同时开的时候，总码率会叠加。如果上行带宽紧张，先降推流码率，不要降录制质量，因为录制文件是留存的，推流是即时的，前者更值得保护。

5.4 长时间运行的资源与稳定性观察

跑了几个小时之后出问题，是最让人崩溃的情况，因为前半小时一切正常，你不会觉得是自己的配置有问题。我这几年遇到过几类典型的长时运行故障：

内存缓慢增长。录制的缓存、场景切换的历史、音视频缓冲都可能慢慢吃掉内存。表现是两小时后开始掉帧且越来越严重。解决办法是设置分段录制，每 30 到 60 分钟切一个文件，同时关掉不必要的预览。

设备发热导致的降频。手机端持续编码会明显发热，屏幕亮度自动降低，画面看起来变暗了。这不是软件问题，物理上解决：取下厚保护壳、避免阳光直射、能插电就插电。

网络侧的长连接被中断。推流一小时后断开，很多是中间设备清理了长时间空闲连接的表现。可以在设置里开启周期性重连，或者把关键帧间隔调短一点，让连接保持活跃。

系统电源策略介入。笔记本合盖、切换电源计划、USB 选择性暂停，都可能在某次空闲后把链路掐掉。我在正式使用前会把电源计划固定成"高性能"，并且把屏幕休眠和睡眠全部关掉。

6. 多链路共存时的抢占、回环与一份可复用的预设

6.1 设备独占与通道抢占的典型现象

多条链路同时开启时，最容易撞上的是设备独占。iOS 设备在某一时刻通常只允许一条屏幕画面通道处于活动状态，如果你先用 USB 连上，再发起 AirPlay，前者会被自动终止；反过来也一样。这个行为本身是合理的，但表现出来非常像故障：画面突然黑掉，你以为线松了，其实是被另一条链路抢走了。

我的处理办法是给每条链路分配明确的使用时段，不在同一时间开两条。如果确实需要冗余，冗余应该放在输出端而不是接入端——比如同时推流和录制，而不是同时用 USB 和 AirPlay 接同一台手机。

另一个抢占点是摄像头设备。有些方案会把投屏画面注册成摄像头，如果物理摄像头和虚拟摄像头同时被不同软件占用，某些会议软件会随机选一个，表现是"有时候是我的手机画面，有时候是我的脸"。这在正式场合相当尴尬，务必在软件设置里锁死设备选择。

6.2 音频回环：最容易被忽略的啸叫来源

音频这条线比视频更容易出事，而且出事的后果更严重——啸叫声一响，整场演示基本就废了。

回环的成因是链路成环：手机投屏的音频输出到电脑，电脑的扬声器声音又被麦克风收进去，麦克风的声音再回到投屏链路里。三个环节任意两个凑在一起就会形成正反馈。常见组合是"电脑外放加手机麦克风"和"会议软件开着免提加独立麦克风"。

我的处理原则很简单：同一条链路上只允许一个拾音源和一个放音源。具体做法是投屏时用耳麦而不是外放；会议软件里把手持设备的麦克风静音；如果必须外放，把麦克风的增益压到很低并且开启回音消除。

还有一个隐蔽的情况：某些方案会把手机自身的音频同时从手机扬声器和电脑输出，形成双声源，听起来像回声但其实是两路声音有时间差。这种情况要在手机端关闭本地播放，只留一路输出。

6.3 一套可直接抄的参数预设与排错速查表

先给预设，覆盖"演示加录制"这个最常见的组合：

画布分辨率: 1920x1080 帧率: 30 投屏接入: USB 有线优先，无线作为备选 投屏输出分辨率: 1920x1080（保持设备原始比例加黑边） 投屏帧率: 30 编码码率: 6 Mbps 关键帧间隔: 2 秒 音频采样率: 48 kHz 录制分段: 每 45 分钟 虚拟摄像头输出: 1920x1080 / 30

再给一张排错速查表，按症状查起，比从头梳理快得多：

最后分享一个我自己一直在用的小技巧：把每次调好的配置导出成独立的配置文件，按场景命名保存，比如"演示-有线-1080p30"、"录课-无线-720p30"。看起来是件小事，但当你在一场重要演示前十分钟发现参数被误改，能一键恢复一套验证过的配置，那种踏实感是值得提前花五分钟准备的。我大概是在第三次临场翻车之后才开始这么做的，之后再没因为配置问题耽误过事。