在 macOS 上，如果你需要远程一台 Windows 服务器，你的第一个选择，大概率会是微软官方的客户端——Windows App。
这很合理：
自家的客户端连接自家的系统，在兼容性、稳定性、协议支持等方面，几乎都是最优解。在“纯 RDP”这件事上，Windows App 的体验确实已经非常成熟。
那问题来了：
既然已经有了官方客户端，为什么我还要再开发一个第三方的 RDP 客户端？
答案并不是「我想重复造轮子」，而是——
Windows App 解决的是“RDP 连接”，但没有解决“真实工作流”。
Windows App 的问题，并不在 RDP 本身
先说清楚一点：
Windows App 不是一个差的产品，但它有非常明确的边界。
1. 不支持批量导入服务器列表
对于只偶尔远程一两台 Windows 的用户来说，这并不是什么问题。
但在需要管理大量 Windows 服务器的场景下，这个限制就会变得非常明显：
- • 服务器数量多（几十台、上百台）
- • 需要按环境区分（测试 / 预发 / 生产）
- • 需要频繁迁移、重装或同步服务器配置
在 Windows App 中，服务器只能一个一个手动添加。
在真实的运维或开发场景下，这种方式的效率非常低。
2. 只支持 RDP 协议（这是最核心的问题）
这一点，才是真正促使我去做 DartShell 的原因。
在真实的工作环境中，我们面对的几乎从来不是一个「纯 Windows 世界」，而更常见的是：
- • Linux 服务器（SSH / Telnet）
- • Windows 服务器（RDP）
- • 老设备或特殊设备（VNC / Telnet）
- • 混合云、本地机房、跳板机
也就是说：
SSH / RDP / Telnet / VNC 混合存在，才是常态，而不是例外。
而 Windows App 只支持 RDP，这意味着：
- • 它注定是一个单一协议工具
- • 在实际工作中，你必须在多个工具之间来回切换：
-
- ○ 一个 SSH 客户端
- ○ 一个 Windows App
- ○ 可能还有其他远程工具
这使得 Windows App 很难成为工作流的“中心”。
工具多不是问题，切换才是问题
很多人会低估「频繁切换工具」带来的成本：
- • 工作上下文被打断
- • 服务器列表、分组、搜索全部是割裂的
- • 心智负担持续累积
在这种情况下，Windows App 更像是：
一个你不得不偶尔打开的独立工具
而不是一个可以长期驻留、承载完整工作流的工具。
DartShell 想解决的，从来不只是 RDP
基于这些真实存在的痛点，我最终开发了 DartShell。
它的目标并不是「再做一个 RDP 客户端」，而是：
把 SSH / RDP / Telnet / VNC 这些常用协议，统一进同一个工作流中。
具体来说：
- • 统一的服务器列表
- • 统一的分组、标签与搜索
- • 支持批量导入与迁移
- • 尽可能减少在不同工具之间来回切换
在 DartShell 中，RDP 只是其中一个重要能力，而不是全部。
那性能和兼容性呢？
这是很多人最关心的问题。
说实话，在一开始做 RDP 的时候，我对标的目标就非常明确：
至少不能明显输给 Windows App。
经过持续的研究和优化，目前在常见使用场景下：
- • 画质表现
- • 编码与解码参数
- • 延迟体验
都已经无限接近 Windows App 的体验。
如果你在 macOS 上搜索 RDP：
- • 排名第一的是 Windows App
- • 排名第二的，就是 DartShell
这至少说明一件事：
在 RDP 这件事上，DartShell 已经进入了可被认真考虑的行列。
总结
Windows App 是一个优秀的 RDP 客户端。
但 DartShell 解决的，是一个更偏向「工作流整合」的问题。
如果你的需求是：
- • 偶尔远程一两台 Windows
那么 Windows App 已经足够好。
如果你的工作环境是：
- • 多协议
- • 多服务器
- • 高频切换
那你真正需要的，可能不是“更好的 RDP”，
而是一个尽可能减少切换成本的一站式工具。
