这一页把散在各页的疑问收在一起，回答尽量带条件或读数。只写可以或不行没有信息量：读者看完仍然不知道自己的机器属于哪种情况，还得再问一遍。
十三类疑问归到四个方向，先定位自己属于哪一类再往下找答案，比从头逐条读要快。每类后面的读数都标了量法，量法不同就不能横着比。
先看这张归位表
四个方向对应四组读数，读数对不上的时候，先回到归位表确认自己问的是不是同一件事。
| 疑问类别 | 先核对什么 | 本站对应读数 | 常见归因 |
|---|---|---|---|
| 安装门槛 | 系统大版本与小版本号 | 官方清单：iOS 13 及以上、Windows 10 1809 及以上 | 低于门槛时装上也会在连接阶段退出 |
| 包体体积 | 完整包还是按架构拆分的主包 | 逐平台称重：iOS 52.9 MB 对 Android 26.7 MB | 统计口径不同被当成同一件事比较 |
| 授权与权限 | 辅助功能、屏幕录制两道是否都授予 | 实测 macOS 端两道缺一不可 | 只授一道，能连上但看不到画面 |
| 外设映射 | 键鼠走蓝牙、OTG 还是有线 | 实测蓝牙键盘 2.4 秒、OTG 6.8 秒 | 供电不足，或应用没有长按菜单 |
归位表四列怎么读
第一列定位问题，第二列给出先核对的那一项，第三列是本站对应的读数，第四列写常见归因。读数对不上时先回第二列，多半是核对项选错了。
- 第二列选错核对项，第三列的读数必然对不上
- 第三列每个读数都标了量法，量法不同不能横着比
- 第四列的归因来自统计，条件不同时可能换成另一种
报疑问时先自己量什么
把三件事量出来再报，答复会具体：系统完整版本号、取包时商店下发的体积、外设走的通道。缺一项只能给范围答案。
- 系统版本写到第三位，只报大版本无法判断是否过线
- 取包体积按商店下发那份记，安装后总占用另记一栏
- 外设通道注明蓝牙或 OTG，OTG 还要写是否带供电
门槛类的三问
门槛问题的共同点是：问的人多半已经装过一次、失败过一次。先分清是装不上还是装上连不上，两者的处理方向完全不同。
门槛三问的共同前提
三条都建立在同一个前提上：先分清是装不上还是装上连不上。前者由商店或安装器拦住，后者能进主界面但连接阶段退出。
- 装不上时商店或安装器直接拦，条件为版本低于官方清单
- 装上连不上时主界面能开，失败点落在连接阶段
- 两类现象混报会被当成同一种版本问题，核对顺序被打乱
系统版本刚好低于门槛，装得上吗？
桌面端会装上但用不了：本站实测比 1809 更早的 Windows 10 能安装成功，连接后黑屏，日志报图形接口缺失；低于 Big Sur 的 macOS 能装上，但授权面板不出现，屏幕录制这道权限永远授不上。
低于 iOS 13 的设备还有办法吗？
没有。App Store 侧直接拦截安装，本站实测低于 iOS 13 的设备在商店页面就无法继续。门槛写的是 iOS 13 及以上，这个版本之下连取包这一步都过不去，与配置无关。
Linux 的 glibc 2.28 是硬要求吗？
是。低于这个版本启动即报线程库版本不足，本站实测低于 glibc 2.28 的发行版在启动阶段直接退出。静态编译版可以试跑，但功能不全，且 x86_64 以外的架构要另外取包。
日志能定位到失败在哪一步
连接阶段失败大多留日志：图形接口缺失、线程库版本不足、授权未授予，三类各对应一条明确记录。先看最后一条错误，再倒着找第一处异常。
- 图形接口缺失的报错指向系统版本，与授权无关
- 线程库版本不足指向 glibc，低于 2.28 的发行版会出现
- 授权未授予时看不到采屏调用，只剩连接建立记录
体积与版本类的三问
体积类疑问多数来自一个误会：把不同统计口径的数字放进同一张排行。先确认手里这个数字是完整包还是主包，再比大小。
体积数字先看口径
同一个客户端能读出至少三个体积：商店公示、安装包、安装后占用。跨页比较只用同一种口径，实测中口径混用时 52.9 MB 与 26.7 MB 的差距会被放大或抹平。
- 商店公示值对应下发的那一份，完整包与主包不同
- 安装后占用含解压与缓存，通常大于安装包读数
- 五个平台的体积逐端单独称重，两次一致才记下
iOS 的 52.9 MB 里装了什么？
完整包内含多套 ARM 指令与图形资源，安装时不再按需取素材，一次到位。代价是首次取包等待更长，收益是断网也能启动；这 52.9 MB 是本站逐平台实测称重后取的读数。
Android 的 26.7 MB 是完整体积吗？
不是。26.7 MB 是主包，部分素材按需下载。把选装部分算进来之后与 iOS 的差距会收窄，但本站这组读数只统计主包，没有把按需部分并入。
五个端必须同版本吗？
大版本一致最稳。本站实测跨大版本连接出现过画面卡顿，同版本没有；升级时尽量五端一起升。跨版本连不上时先对齐版本，再去排查网络与授权。
版本对齐的检查次序
跨版本连线出问题，顺序是先大版本、再小版本、最后看平台分支。大版本不一致时后续检查意义不大，症状会被版本差异掩盖。
- 先比大版本，不一致时优先升级再复测同一组操作
- 大版本一致再看小版本，小版本差异多表现为偶发卡顿
- 同版本不同平台分支分别记录，不能合并成一条结论
授权与外设类的四问
授权归系统管，映射归应用管，客户端只能把事件递过去。递不过去的时候它自己也没法绕过，这一层的边界要提前知道。
两道授权对应的两种症状
辅助功能管输入事件能不能递过去，屏幕录制管画面能不能取到。缺一道的症状不一样，据此可直接判断补哪一道，不必两道都重授。
- 缺辅助功能：能连上，键鼠事件传不过去，画面正常
- 缺屏幕录制：能连上，画面黑着，指针事件反而有反应
- 两道都授予才算通，授权后需重启客户端重新读取
macOS 首次启动要授几个权限？
两道：辅助功能与屏幕录制，缺一道的表现不同。缺辅助功能是能连上但键鼠事件传不过去，缺屏幕录制是能连上但看不到画面，两道都授予才算通。
授权之后还是不生效，怎么办？
重启一次客户端。授权状态在进程启动时读取，不重启会出现已经授权但仍然不生效的假象；重启后仍无效，去系统设置里手动添加应用再试。
手机接有线键鼠为什么没反应？
iOS 端要走 OTG，且转接器必须带供电。本站实测识别耗时 6.8 秒，不供电则识别失败；供电到位后还要注意先供电再插键鼠，顺序反了会在中途掉线。
鼠标右键在移动端怎么用？
被映射成长按。本站实测四组常用应用全部生效，判定标准是长按后弹出应用自己的上下文菜单；应用本身没有长按菜单时，右键没有任何反应。
映射失效先分清是谁的边界
右键没反应有两种来源：映射层没把事件翻译过去，或应用没注册长按菜单。前者换应用能复现，后者只在特定应用里出现，换一个支持长按的应用一试就能分开。
- 换应用后恢复，说明目标应用没有长按菜单
- 换应用仍无反应，先查映射开关与连接状态
- 四组常用应用实测全部生效，超出这四组需单独试
互控与后台类的三问
互控方向的疑问集中在读数的量法上：同一个数字，量的是握手、是首帧、还是码流，含义差别很大，量法混用就会得出互相矛盾的结论。
量法不同不要横着比
三个互控读数分别量握手、编码与落盘：36 毫秒是首帧落地，15 Mbps 是单向码流，9.6 MB/s 是文件落盘。单位不同，实测的大小顺序说明不了体验好坏。
- 实测 36 毫秒对应连接建立那一下，与后续操作耗时无关
- 实测 15 Mbps 按平台分开取单向，双向叠加会翻倍
- 实测 9.6 MB/s 只在传文件时读，含两端读写开销
桌面控移动和移动控桌面手感一样吗？
不一样。桌面控移动时对端是竖屏比例，横向内容被裁切，要频繁滚动；移动控桌面时画面缩到手机屏上字很小。36 毫秒的首帧落地两边一样，操作体感不一样。
静置时码流为什么比 15 Mbps 低很多？
画面定住后码流自然掉下来，这是编码器的正常行为。15 Mbps 是本站实测、按平台分开取单向码流的读数，峰值只描那一帧，不摊成持续值，所以静置值低不等于连接质量差。
移动端挂后台会被回收吗？
会。实测常驻内存 97 MB 是挂在后台不动时的读数，平台分开记；内存紧张时移动端进程仍会被系统回收，表现为连接突然断开，重连后恢复，正在传的文件会从头开始。
后台被回收之后的恢复动作
进程被回收后连接断开，恢复分三步：回到前台重连、确认上次未完成的传输、按需重发。传输中断时已传部分不保留，重连后从头发起。
- 回前台重连，条件为移动端且应用被系统回收过
- 确认未完成传输的状态，中断文件不保留已传部分
- 常驻内存 97 MB 是后台不动的实测读数，内存紧张时仍被回收
回答里没写到的部分
本页所有读数都来自同一套对照机，采样自 2026-10-24 起累计 305 次并取中位。换机器、换系统分支、换网络环境都要重新取样，这里的数字只能当参照，不能当保证。
如果你的现象与本页描述不一致，先核对三件事：系统版本是否达到门槛、授权是否两道都给了、外设走的是哪条通道。这三件对上之后仍然不一致，再按勘误渠道反馈具体平台与版本号。
本页没写到的两类情形
两类情形没有覆盖：一是自定义网络环境下的读数，二是厂商定制系统分支的表现。共同点是变量太多，同一台机器换一次条件结论就变。
- 自定义网络（代理、内网穿透）下的首帧落地需重新采样
- 厂商定制分支的省电策略差异大，读数按机型分别取
- 两类都建议先记录环境再报读数，否则无法复现