温馨提示：
本文所述内容具有依赖性，可能因软硬条件不同而与预期有所差异，故请以实际为准，仅供参考。
背景
在 macOS 上部署 RustDesk 作为远程控制工具时，常见的做法是先通过系统自带的 VNC（Screen Sharing）进行初始配置。然而，在实际操作中，可能会遇到一系列看似“诡异”的问题：
- RustDesk 反复上线 / 下线
- RustDesk 显示“未就绪，请检查网络连接”和“就绪”状态来回跳转
- RustDesk 的连接密码不断变化
- 系统反复弹出提示：
“RustDesk 正在请求绕过系统无痕浏览窗口选择器…”
- 即使已经授权了 屏幕录制 / 辅助功能 / 输入监控，问题依旧存在
- 在 VNC 会话中点击“允许”或“打开系统设置”没有任何反应
这些现象极易被误判为网络问题、RustDesk Bug 或权限没给全。
结论先行
这不是 RustDesk 的 Bug，也不是权限配置错误，而是 macOS 的安全模型导致的“资源互斥”。
macOS 不允许系统自带 VNC（Screen Sharing）与第三方远程控制工具（如 RustDesk）同时占用屏幕捕获上下文。
当 VNC 会话存在时，RustDesk 无法完成屏幕捕获初始化，从而触发权限异常与服务重启。
关键现象背后的真实原因
1. macOS 的屏幕捕获是“独占资源”
自 macOS 10.15 起：
- 屏幕捕获（ScreenCaptureKit / CGDisplayStream）为高安全级别资源
- 同一时间只能存在一个“主屏幕捕获上下文”
- 系统自带的 VNC（Screen Sharing）拥有最高优先级
当 VNC 连接存在时：
- RustDesk 启动不会失败
- 但无法获得完整的屏幕捕获能力
- 系统会将其行为判定为“异常捕获请求”
于是出现那条极具误导性的提示。
2. 权限已授权，但 TCC 状态被卡死
在 VNC 会话中首次触发权限请求 会导致：
- 权限弹窗显示
- 用户点击“允许”
- 但 TCC（隐私权限数据库）并未成功写入
系统却认为该请求已经发生过，导致：
- 无法重新请求
- 已授权但不生效
- RustDesk 进入权限死循环
3. 为什么密码一直变、状态反复跳
RustDesk 的内部逻辑是：
- 权限正常 → 启动完整服务 → ID / 密码稳定
- 权限异常 → 服务反复重启 → 每次生成临时凭据
因此：
- 密码一直变化 = RustDesk 进程被 macOS 不断杀掉重启
- “就绪 / 未就绪”跳转并非网络问题，而是权限初始化失败
为什么关闭 VNC 后一切恢复正常
当关闭系统 VNC（Screen Sharing）后：
- 屏幕捕获资源被释放
- RustDesk 能成功初始化捕获上下文
- 权限校验通过
- 服务稳定运行
这正是问题的根本验证。
正确、稳定的使用方式
推荐方案（长期稳定）
配置阶段
- 使用系统 VNC
- 不启动 RustDesk
正式远程阶段
- 关闭系统 VNC（系统设置 → 共享 → 屏幕共享）
- 仅使用 RustDesk
这是 macOS 下唯一不会反复踩坑的组合方式。
不推荐但可能“看起来能用”的方式
- VNC 开启但不连接
- RustDesk 同时运行
这种状态下：
- RustDesk 极易再次进入权限异常
- 问题随时复发
一句话总结
macOS 上，系统 VNC 与 RustDesk 并非“软件冲突”，而是“安全模型下的资源互斥”。只要理解这一点，所有看似诡异的现象都会变得合理。
经验教训
- 不要在 VNC 会话中首次启动需要屏幕权限的应用
- 包括 RustDesk、AnyDesk、TeamViewer、OBS 等
- 首次授权一定要在本地物理会话完成
