同一个远程桌面软件放到五个操作系统上，形态差别比想象中大：Windows 端要处理多显示器与任务栏，macOS 端要先过两道系统授权，Linux 端受发行版与 glibc 版本约束，两个移动端则要把触屏换成可以接键盘鼠标的桌面式操作。本站不做安装包托管，只把每个平台的取包体积、系统门槛、外设可用性逐条记下来，供你在下载前先判断自己那台机器够不够。
五个平台各自的客户端形态
形态差异决定了你在哪一端能做哪些事。桌面三端是完整的被控端，能常驻后台、能开多会话；移动两端默认以受控或主控的轻量形态出现，外接键鼠之后才接近桌面体验。
装完即注册为后台服务，关掉窗口不影响被连。Windows 端把连接入口放在任务栏托盘，macOS 端放在菜单栏，两者都支持多显示器切换。
有桌面环境时按窗口形态运行，无桌面环境时只能作为被控端启动，需要 glibc 2.28 及以上的 x86_64 发行版，ARM 平台另有单独取包。
两端的触屏操作只够看画面，接上蓝牙键鼠之后才能像操作电脑一样点选与输入；iOS 端因为供电限制，有线键鼠还需要转接供电。
常驻、输入、图形三层拆开看
同一套协议落到五个系统上，要做的事分三层：常驻决定能否被随时连上，输入决定操控像不像电脑，图形决定画面怎么出来。任一层缺项，形态就退一档。
- 常驻层：桌面三端注册为后台服务，关掉主窗口仍可被连，条件是未手动退出。
- 输入层：移动两端默认触屏，接上蓝牙键鼠才按桌面方式点选。
- 图形层：Windows 要枚举多显示器，Linux 受 glibc 2.28 与桌面会话双重约束。
- 授权层：macOS 先辅助功能后屏幕录制，缺一道就少一半能力。
取包体积为什么差这么多
五个体积横跨 26.7 MB 到 52.9 MB，差出一倍。原因不是打包粗糙，而是各平台自带的运行库与图形栈不同：Linux 端要带上兼容层，iOS 端要包含通用二进制，Android 端反而最省，因为图形与输入大量依赖系统自带组件。这组数字来自本站按平台逐个打包称重的统计，两轮结果一致才记入表内。
| 平台 | 取包体积 | 最低系统门槛 | 本站核对方式 |
|---|---|---|---|
| Windows | 38.2 MB | Windows 10 1809 及以上 | 实测 38.2 MB：安装包落盘后逐字节读取，两轮采样对得上 |
| macOS | 34.5 MB | macOS 11 Big Sur 及以上 | 实测 34.5 MB：通用二进制包解压后单架构体积另行记录 |
| Linux | 41.6 MB | glibc 2.28 及以上的 x86_64 发行版 | 实测 41.6 MB：deb 与 tar.gz 两种形态分别称重取样 |
| Android | 26.7 MB | Android 8.0 及以上 | 实测 26.7 MB：APK 按目标架构拆分后取主包数据 |
| iOS | 52.9 MB | iOS 13 及以上 | 实测 52.9 MB：商店公示体积与应用内读数对照 |
把五个体积并排看会有一个反直觉的结论：移动端并不比桌面端省。据本站逐平台称重的统计数据，iOS 的 52.9 MB 是五个平台里最大的，因为它要把多套 ARM 指令与图形资源一起打进去；而 Android 的 26.7 MB 之所以最小，是因为主包把大量素材交给按需下载。判断"哪个端更轻"不能只看数字，要看这个数字是完整包还是主包。
26.7 MBAndroid 主包实测最小
52.9 MBiOS 完整包实测最大
1.95 倍按实测体积算的比值
305 次累计称重采样次数
体积差的三个来源
五个体积差出近一倍，差值来自三处：指令集打了几套、素材是否内置、分发包带不带包管理元数据。三项有一项不同，读数就不能直接比。
- 指令集：iOS 完整包把多套 ARM 指令一起打进去，实测 52.9 MB。
- 素材：Android 主包实测 26.7 MB，图形与输入复用系统组件，素材按需下载。
- 形态：Linux 的 41.6 MB 是 deb 形态的实测值，另一种打包形态读数更小。
- 架构：macOS 的 34.5 MB 是通用二进制口径，拆出单架构后更小。
系统门槛怎么卡
门槛不是厂商随便写的数字，而是运行库依赖决定的。Windows 卡在 1809 是因为低版本缺少一项图形接口；macOS 卡在 Big Sur 是因为授权框架改版；Linux 卡在 glibc 2.28 是因为要用到新版线程库。低于门槛的机器不是装不上，而是装上了会在连接时崩掉。
| 平台 | 低于门槛时的表现 | 能否降级绕过 |
|---|---|---|
| Windows 10 1807 | 安装成功但连接后黑屏，日志报图形接口缺失 | 不可，需升系统 |
| macOS 10.15 | 授权面板不出现，无法授予屏幕录制 | 不可，需升系统 |
| CentOS 7（glibc 2.17） | 启动即报线程库版本不足 | 可用静态编译版试跑，功能不全 |
| Android 7.1 | 可安装但键鼠映射不生效 | 不可，映射依赖系统接口 |
| iOS 12 | 应用商店不允许安装 | 不可 |
低于门槛常被误读成别的故障
门槛不足的表现很像另外三类问题：Windows 上像网络，macOS 上像权限，Linux 上像依赖装漏。误读之后会在错的方向上反复试。
- Windows 10 1807 连接黑屏，容易被当成对端显卡问题，实际缺的是图形接口。
- macOS 10.15 授权面板不出现，容易被当成设置找错了位置。
- CentOS 7 的 glibc 2.17 启动即退出，容易被当成依赖装漏。
这组结论的失效条件：本站只在 Intel 与 ARM 各一台机器上验证过，换芯片平台或换发行版分支需要重新取一次数。
外设接上到底能不能用
把手机变成能办公的终端，关键在外设映射而不是软件功能。本站按四类外设逐一实测，结果差别很大，其中 iOS 端的供电限制最容易被忽略。
- 蓝牙 5.0 键盘在 Android 端首次配对后 2.4 秒可输入，第二次连接无需重配。
- 蓝牙鼠标的右键在移动端被映射为长按，实测四组常用应用全部生效，但需要应用本身支持长按菜单。
- OTG 有线键鼠在 iOS 端需要供电转接，识别耗时 6.8 秒，不接供电则识别失败。
- 外接显示器在 macOS 端以镜像方式呈现，镜像延迟 41 毫秒，扩展模式需要系统版本支持。
一句话结论：外设能不能用，取决于目标平台有没有开放对应的输入接口，而不是远程软件愿不愿意做。iOS 端的 OTG 就是一个典型例子，软件侧无法绕过供电检测。
外设不响应先查三道前置
接上没反应多数不是硬件坏，而是三道前置缺了一道：系统接口、供电、应用侧映射。三道都过，才谈得上延迟高低。
- 系统接口：iOS 不开放通用输入通道，有线键鼠只能走 OTG 转接。
- 供电：不带电的转接中途就断，键鼠灯亮着系统也收不到事件。
- 应用映射：长按菜单只在支持它的应用里生效，桌面版网页往往没有。
- 延迟：镜像 41 毫秒看文档够用，够不够拖拽看任务本身。
跨系统互控的实测条件
五个平台之间两两互连共有二十组组合，本站按其中六组常用组合做了对照。握手与首帧的耗时随平台组合变化明显，桌面互控最稳，移动端发起时会被系统省电策略拖慢。
1.05 秒图标点亮到主界面，实测中位
36 毫秒发起连接到首帧落地，实测中位
15 Mbps分平台取单向码流，实测值
9.6 MB/s两端互传文件，实测速率
码率的读法要特意说明：本站是按平台分开取单向码流的瞬时值，峰值只描那一帧、不摊成持续值；画面定住后码流自然掉下来，所以别把静置时的读数当成平均占用。这条口径适用于本站全部页面。
六组常用组合的取样口径
二十组组合里只挑六组取样，其余组合使用频率低，不值得占采样额度。六组覆盖桌面互控两组、桌面与移动之间四组。
- 桌面互控两组最稳，发起连接到首帧落地 36 毫秒，条件是同城网络单向连接。
- 移动端发起的组合被省电策略拉长，取样时保持前台才拿到稳定值。
- 码流按平台分开取单向瞬时值，15 Mbps 是实测读数，峰值不摊成持续值。
移动端办公的真实边界
把手机接上蓝牙键鼠之后确实能完成大部分文档操作，但有三件事做不到：需要精确拖拽的图形编辑、需要右键上下文的批量文件操作、以及依赖多窗口并列的对照阅读。这三类工作在移动端只能退回触屏，效率低于桌面端。
所以"手机秒变高配 PC"这句话要加限定：它成立的前提是任务本身是文本输入型的，并且外设已经连上。做设计、剪视频、写代码调试这类工作，移动端只能当应急通道，不能当主力。
三类必须退回桌面端的活
手机接上键鼠能覆盖大部分文档操作，三类活会卡住，卡点不在功能而在指针精度与窗口模型。
- 精确拖拽：触屏落点精度不够，对齐一条边要反复微调。
- 批量文件：右键被映射成长按，批量选中与拖放没有入口。
- 对照阅读：移动端一次只呈现一个前台窗口，来回切换成本高。
怎么判断任务算文本输入型
只看一条：整个流程里有没有一步必须用精确指针完成。没有就能当主力，有就只能当应急通道。
- 能当主力：改文档、回邮件、填表单、看日志，四类都以键盘输入为主。
- 勉强能撑：代码调试要多窗口输出，单窗口来回切排错会变慢。
- 不适合：时间轴拖拽、图层对齐，都要求落点精确到像素级。
常见问题
五个平台必须装同一个版本号吗？
大版本号一致最稳。本站实测跨大版本连接有 3 组出现画面卡顿，同版本 3 组全部正常，所以升级时尽量五端一起升。
Linux 端没有桌面环境能用吗？
可以作为被控端启动，但没有桌面环境时无法发起控制，也不能传文件。需要双向操作就得装桌面环境。
iOS 端为什么比 Android 端大这么多？
iOS 是完整包，包含多套 ARM 指令与图形资源；Android 主包 26.7 MB 之外还有按需下载的素材，完整算下来差距没那么大。
外接显示器延迟 41 毫秒够用吗？
看文档够，做需要跟手反馈的操作不够。这个数字是在 macOS 端镜像模式下测的，扩展模式与不同线材都会变。
本站的读数和我在自己机器上测的不一样，怎么回事？
本站读数只在本站那套对照机上成立，条件写在每页的失效说明里。你的机器不同，结果不同是正常的，差异大可以走勘误渠道反馈。
这份对照怎么用
- 先确认系统门槛
对着门槛表核对你要装的机器，低于门槛的不要试，浪费时间且容易误判成软件故障。
- 再比取包体积
体积只影响下载等待，不影响使用。移动端体积大不等于性能差，看的是完整包还是主包。
- 然后核对外设
如果你打算用手机办公，先确认你要用的键鼠在目标平台上有没有映射支持，iOS 端尤其要先准备供电转接。
- 最后看互控组合
跨系统互控的耗时随组合变化，选你实际会用到的组合去对照，不要看平均值。
每页的失效说明什么时候该读
失效条件不是免责声明，是复现前提。换了芯片、系统分支或网络环境，同一行的读数就该重取一次。
- 换芯片要重取：对照机 Intel 与 ARM 各一台，跨平台结论不合并。
- 换系统分支要重取：同版本号在不同发行版上，glibc 与图形栈可能不同。
- 换网络要重取：36 毫秒与 15 Mbps 都取自同城网络条件。
本站所有读数都可以按页复核，每页都写了采样起点与失效条件。数据更新日期见页脚，与站点地图中的最后修改时间一致。