izum

给 AI 足够上下文，能把 Slint 搬到 ESP32 上吗？

Sun, 26 Jul 2026 00:00:00 GMT

我一开始有一个很直接的想法：只要给 AI 足够多的上下文，它应该就能完成大部分项目。

这次我拿一块微雪 ESP32-S3-Touch-LCD-1.85C 做了实验。官方主要提供 Arduino、ESP-IDF 和 LVGL 示例，而我想走一条并不在官方 Demo 里的路线：使用 Rust 驱动整块开发板，再把 Slint 的 GUI 跑到这块 360 × 360 的圆形触摸屏上。

最后，屏幕成功点亮，Slint 界面能够正常渲染，触摸也可以转换为界面事件。项目已经公开在 GitHub：izumkineno/esp32_slint_waveshare。

[!NOTE] 本文先记录从官方 Demo 到 Rust、再到 Slint 的移植过程。开发板实拍和运行界面截图将在后续更新中补充。

我真正想验证的是什么

如果只把一句“帮我给 ESP32 写个 Slint GUI”交给 AI，得到的结果很可能只是能够解释概念、却无法在真实硬件上工作的代码。

嵌入式开发的问题不只在语言和框架。屏幕型号、总线协议、GPIO 映射、复位顺序、初始化命令、像素格式、内存位置和工具链版本，任何一项错误都可能让设备停在黑屏。AI 并不知道我手里这块板子的实际连接方式，也无法凭空判断厂商 Demo 中哪些步骤不能省略。

所以这次实验里的“足够上下文”，并不是简单地把大量文件塞进提示词，而是给出一条可以追溯的证据链：

微雪官方硬件文档负责说明板载器件和基础规格。
官方 Arduino 与 ESP-IDF 的 LVGL Demo 负责说明这块板子实际上如何初始化和通信。
esp-hal 与 Rust 工程负责约束目标平台、所有权模型和 no_std 环境。
embedded-graphics先验证底层显示与触摸链路。
Slint 源码负责回答框架在没有桌面窗口系统时如何接入自定义平台和显示设备。
编译、烧录和真实触摸操作负责验证结果，而不是让“代码看起来合理”成为终点。

这条链路把一个模糊目标拆成了可以逐层验证的问题。

第一步：从 LVGL Demo 中提取硬件使用方式

目标开发板的核心硬件是：

模块	型号与配置
主控	ESP32-S3，最高 240 MHz
存储	16 MB Flash、8 MB Octal PSRAM
LCD	ST77916，1.85 英寸，360 × 360，RGB565
LCD 总线	QSPI
触摸	CST816S，I2C 单点电容触摸
IO 扩展	TCA9554PWR
RTC	PCF85063

硬件介绍只能告诉我“有什么”，真正决定驱动能否工作的，是 Demo 告诉我的“怎么用”。我让 AI 同时阅读官方 Arduino 和 ESP-IDF 示例，把信息整理成独立的硬件笔记，而不是直接照抄某一套 C/C++ API。

提取出的关键连接包括：

信号	配置
I2C SDA / SCL	GPIO11 / GPIO10，400 kHz
TCA9554PWR	I2C 地址 `0x20`
LCD reset	TCA9554PWR EXIO2
Touch reset	TCA9554PWR EXIO1
LCD QSPI SCK	GPIO40
LCD QSPI D0 / D1 / D2 / D3	GPIO46 / GPIO45 / GPIO42 / GPIO41
LCD CS	GPIO21
LCD backlight	GPIO5
CST816S	I2C 地址 `0x15`，中断 GPIO4

更重要的是初始化顺序：先建立 I2C，再配置 TCA9554PWR；通过扩展 IO 释放 LCD 复位后，才能初始化 ST77916；触摸控制器也依赖同一条 I2C 和另一根扩展复位线。

I2C
  ↓
TCA9554PWR
  ├─ EXIO2 → LCD reset
  └─ EXIO1 → Touch reset
       ↓
ST77916 QSPI + CST816S I2C

ST77916 也不是“把像素通过 SPI 发出去”这么简单。Rust 驱动最终保留了 Demo 中能够被验证的面板命令流：低速读取面板信息、软件复位并等待、切换到 40 MHz QSPI、设置 RGB565 像素格式、发送厂商初始化表，最后打开显示。

这一步让我确认了一件事：厂商 Demo 不只是示例代码，它还是硬件行为的可执行文档。 AI 的价值在于跨 Arduino、ESP-IDF 和芯片资料提取不变量，再把它们映射到新的语言与 HAL，而不是逐行翻译 API。

第二步：先做 `esp_learn` 亮屏实验

我没有直接把 Slint 接上去，而是先建立了 esp_learn。这个工程只解决三个问题：

Rust 能否通过 esp-hal 正确初始化 ST77916；
embedded-graphics 能否在圆屏上绘图；
CST816S 的触摸坐标能否进入 Rust 主循环。

St77916Display 实现 embedded_graphics::DrawTarget，颜色格式使用 Rgb565。360 × 360 × 2 字节的完整 framebuffer 大约是 253 KiB，因此它被放在静态存储区，而不是入口任务的栈上。绘制完成后，再通过 QSPI 把 framebuffer 刷到 LCD。

圆形面板的控制器仍暴露 360 × 360 的方形地址空间。实验程序先把整个区域填黑，再绘制直径 356 像素的白色圆形画布；触摸命中判断也使用相同的圆形边界，避免在物理屏幕之外的四角继续绘图。

最终的实验很简单：在屏幕上拖动可以画线，点击 CLEAR 可以清空画板。它没有复杂 UI，却验证了完整的最小闭环：

触摸坐标 → Rust 输入逻辑 → embedded-graphics → RGB565 framebuffer → ST77916 QSPI

这一步非常关键。假如我一开始就引入 Slint，那么黑屏可能来自面板初始化、像素字节序、渲染器、内存分配或事件循环中的任何一层。先让 embedded-graphics 亮屏，相当于把后续问题收敛成“如何把 Slint 的输出和输入接到已经工作的驱动上”。

第三步：从 Slint 源码里找移植接口

确认硬件链路后，我把 Slint 的源码拉到本地，让 AI 不再猜测框架应该怎样移植，而是直接查找已有的 MCU、软件渲染器和自定义 Platform 实现。

最终找到的关键接口是：

Platform：为没有桌面窗口系统的目标提供窗口和时间来源；
MinimalSoftwareWindow：在裸机或 RTOS 环境中承载 Slint 窗口；
SoftwareRenderer：把 Slint 场景渲染为软件像素；
LineBufferProvider：逐行接收渲染结果并交给显示驱动；
WindowEvent：把触摸坐标转换为按下、移动、释放和离开事件。

工程关闭了 Slint 的默认功能，只保留 MCU 移植需要的部分：

slint = { version = "=1.16.0", default-features = false, features = [
    "compat-1-2",
    "unsafe-single-threaded",
    "libm",
    "renderer-software",
] }

构建脚本使用 EmbedForSoftwareRenderer 编译 .slint 文件并把所需资源嵌入固件。no_std 环境下 Slint 仍需要动态分配，因此工程在创建任何 Slint 对象之前初始化板载 Octal PSRAM allocator。

渲染侧则使用 RepaintBufferType::ReusedBuffer 和一条 360 像素的 RGB565 行缓冲：

let window = MinimalSoftwareWindow::new(RepaintBufferType::ReusedBuffer);
window.set_size(PhysicalSize::new(360, 360));

let mut line_buffer = [Rgb565Pixel(0); 360];
window.draw_if_needed(|renderer| {
    renderer.render_by_line(DisplayLineBuffer {
        display: &mut display,
        buffer: &mut line_buffer,
    });
});

DisplayLineBuffer::process_line() 让 Slint 先填充需要重绘的行片段，再调用显示驱动的 write_line()。驱动把行号和像素范围转换成 ST77916 的写入窗口，随后用 QSPI 发送 RGB565 数据。

Slint scene
    ↓
MinimalSoftwareWindow + SoftwareRenderer
    ↓
LineBufferProvider
    ↓
360 像素 RGB565 行缓冲
    ↓
ST77916 局部窗口 + QSPI

与 esp_learn 的完整 framebuffer 相比，这条路径不需要为 Slint 再准备一张 360 × 360 的整屏缓冲。单行 RGB565 像素本身只有 720 字节，渲染完成后就可以直接写入屏幕。

输入方向正好相反：轮询 CST816S 得到坐标后，第一次接触发送 PointerPressed，坐标变化发送 PointerMoved，触摸结束发送 PointerReleased 和 PointerExited。这样 Slint 控件并不需要知道底层使用的是哪一款触摸芯片。

从亮屏到真正的 GUI

完成 Platform、渲染和输入适配后，我先做了一个 360 × 360 的圆形控制界面：触摸按钮可以更新计数，CLEAR 可以清零，动画页面用于确认定时器和连续重绘能够运行。

最初的成功版本证明了下面这条链路可以成立：

微雪 LVGL Demo
    ↓ 提取硬件事实
Rust + esp-hal 驱动
    ↓ 验证显示和触摸
embedded-graphics 亮屏实验
    ↓ 替换图形层
Slint no_std software renderer
    ↓
ESP32-S3 圆屏声明式 GUI

项目后来继续加入了时钟、RTC、WiFi、Bluetooth LE 和更多圆屏页面，但这些都建立在最初的显示、触摸和 Slint 平台适配之上。本文记录的重点仍是第一次把 Slint 真正跑上这块开发板的过程。

实际工程与构建说明：https://github.com/izumkineno/esp32_slint_waveshare

这次实验后，我重新理解了“足够的上下文”

实验结果基本支持我最初的判断，但也给它加上了几个前提。

1. 上下文的质量比数量重要

官方文档、厂商 Demo、目标框架源码、确定的工具链版本和真实编译错误，都是高价值上下文。论坛里缺少版本和硬件条件的零散代码，即使很多，也可能把 AI 带到错误方向。

2. 先建立可验证的中间结果

esp_learn 不是多余的临时工程。它把“移植 Slint”拆成了“先让 Rust 可靠控制硬件”和“再替换图形层”两个可验证阶段。AI 可以快速生成和修改代码，但物理世界仍需要亮屏、触摸和烧录结果来裁决对错。

3. 源码可以成为最精确的提示词

当高层文档没有覆盖我的硬件组合时，Slint 源码中的 MCU 适配方式比继续追问“应该怎么做”更有效。让 AI 在源码里查找 MinimalSoftwareWindow、LineBufferProvider 和软件渲染流程，得到的是框架已经支持的扩展点，而不是一套平行实现。

4. 人仍然要定义边界和验收条件

AI 可以帮助阅读、归纳、移植和排错，但“先验证哪一层”“什么结果算成功”“哪些资料可信”仍需要人来决定。这次的验收条件一直很具体：能编译、能烧录、能亮屏、能接收触摸、能让 Slint 控件响应。

所以我现在会把最初的想法改写成：

对于边界能够描述、结果能够验证的项目，只要向 AI 提供足够准确且结构化的上下文，它确实可以完成很大一部分工程工作。

这不是让 AI 凭空替代嵌入式开发，而是把硬件文档、厂商实现、框架源码和真实设备组织成一个能够持续验证的工作环境。对我来说，这次从 LVGL Demo 到 Rust，再到 Slint 的移植，就是这套方法第一次完整跑通。

68 元捡来一台阿里云 200 Mbps 小服务器：搭建 EasyTier 与 RustDesk 中继

Wed, 17 Jun 2026 00:00:00 GMT

最近用向日葵远程电脑时，我越来越受不了它的延迟：画面更新慢、操作有明显的黏滞感，网络稍有波动就更难受。单纯换一个远程桌面客户端并不能解决所有问题，真正影响体验的还有连接路径——只要流量绕得足够远，再好的客户端也救不回来。

我由此想起了以前开《方舟：生存进化》和 Minecraft 服务器时留下的两套工具：EasyTier 和 Sakura Frp。当时为了让不同网络下的朋友加入服务器，我没少折腾 P2P 打洞、端口映射和中转节点。这次干脆把旧方案重新组合，看看能不能搭一套延迟更低、路径更可控的远程桌面环境。

从游戏联机方案想到远程桌面

国内家庭宽带普遍没有可直接入站的独立公网 IPv4，不少线路还处于运营商 CGNAT 后面。EasyTier 会优先尝试 NAT 穿透，但两端 NAT 类型、运营商策略或防火墙不合适时，P2P 连接仍然可能失败。

我最早采用的办法是：

在一台没有公网 IP 的设备上运行 EasyTier，让它监听本地端口。
使用 Sakura Frp 把 EasyTier 的监听端口映射到一个公网节点。
其他设备通过 Sakura Frp 节点提供的域名和端口加入 EasyTier 网络。
EasyTier 能打洞时尽量走 P2P；打洞失败时，通过指定的中转路径保持可用。

这套方案的关键不是“消灭延迟”，而是把不可控的绕路收敛到一个位置合适的中转节点。最终延迟仍取决于中转机房、双方运营商线路、网络拥塞和丢包率，但通常会比随机分配、路径不可控的公共远控服务稳定。

后来我准备把同一思路用到 RustDesk 上：先用 EasyTier 建立虚拟局域网，再把自建的 RustDesk ID 服务和中继服务放进这个网络。结果看 Sakura Frp 套餐时，发现当时最低的青铜 VIP 也要 10 元/月。价格可能随时调整，但这已经足够让我继续逛一圈云服务器。

然后我碰到了这台小机器：2 核 CPU、2 GiB 内存、40 GiB 系统盘，峰值公网带宽 200 Mbps，还带独立公网 IP。价格只要 68 元，于是直接开干。

需要注意，页面标注的是峰值公网带宽，不等于任何时刻都能稳定跑满 200 Mbps。实际吞吐还会受实例限速、共享出口、线路质量和流量配额影响。对远程桌面来说，稳定延迟和低丢包通常比峰值数字更重要。

最终方案

这台服务器同时承担两个职责：

EasyTier 固定节点：所有设备先加入同一个加密虚拟网络；能直连时走 P2P，不能直连时由服务器协助转发。
RustDesk 服务端：运行 hbbs（ID/信令服务）和 hbbr（中继服务），远控双方通过 EasyTier 虚拟 IP 访问它们。

远控端 ─┐
        ├─ EasyTier 虚拟网络 ─ 阿里云服务器（10.144.144.1）
被控端 ─┘                         ├─ hbbs：ID/信令
                                 └─ hbbr：远程桌面中继

这样做有两个好处：

公网侧原则上只需要开放 EasyTier 的入口，RustDesk 端口可以只允许虚拟网段访问。
如果将来更换云服务器，只要保留 EasyTier 网段、RustDesk 数据目录和公钥，客户端配置基本不需要重做。

下面以 Debian/Ubuntu 系统和 Docker Compose 为例。命令中的网络名称、密码、公网 IP 都必须替换为自己的值，不要把真实密码、Sakura Frp 访问密钥或 RustDesk 私钥写进公开文章。

一、准备服务器

先更新系统并安装 Docker。Docker 的安装方式会随发行版变化，建议直接参考 Docker 官方安装文档，不要长期依赖来历不明的一键脚本。

确认 Docker 和 Compose 可用：

docker --version
docker compose version

在阿里云安全组中开放：

端口	协议	用途
`11010`	TCP	EasyTier 节点连接
`11010`	UDP	EasyTier UDP 连接和更低延迟的直连尝试

如果只准备通过 EasyTier 虚拟网络使用 RustDesk，就不需要在云安全组中公开 21115—21117。若服务器启用了 UFW，可以先放行 EasyTier：

sudo ufw allow 11010/tcp
sudo ufw allow 11010/udp

安全组对外开放时无法限制动态家庭宽带的来源地址，因此一定要使用足够长且随机的 EasyTier 网络密码。

二、部署 EasyTier

创建工作目录：

sudo mkdir -p /opt/easytier
cd /opt/easytier
sudo nano compose.yml

写入以下配置：

services:
  easytier:
    image: easytier/easytier:latest
    hostname: aliyun-relay
    container_name: easytier
    restart: unless-stopped
    network_mode: host
    cap_add:
      - NET_ADMIN
      - NET_RAW
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - /etc/machine-id:/etc/machine-id:ro
    command: >
      -i 10.144.144.1
      --network-name YOUR_NETWORK_NAME
      --network-secret YOUR_STRONG_SECRET
      --private-mode true

这里的参数含义：

-i 10.144.144.1：给服务器分配固定的 EasyTier 虚拟 IP。
--network-name：虚拟网络名称，所有设备必须一致。
--network-secret：虚拟网络密码，所有设备必须一致。
--private-mode true：只允许网络名称和密码匹配的节点加入。
network_mode: host：让容器直接使用宿主机网络。
/dev/net/tun、NET_ADMIN 和 NET_RAW：创建虚拟网卡所需的权限。

启动服务：

sudo docker compose up -d
sudo docker compose logs -f easytier

首次验证完成后，建议把 latest 换成当时确认可用的具体版本，避免未来自动拉取到不兼容更新。

三、让电脑加入 EasyTier 网络

在远控端和被控端安装 EasyTier。官方提供 Windows、Linux、macOS 等平台的 GUI 和命令行版本，本文只展示命令行参数。

被控端可以使用固定虚拟 IP：

sudo easytier-core \
  -i 10.144.144.2 \
  --network-name YOUR_NETWORK_NAME \
  --network-secret YOUR_STRONG_SECRET \
  -p tcp://SERVER_PUBLIC_IP:11010 \
  -p udp://SERVER_PUBLIC_IP:11010

远控端使用另一个地址：

sudo easytier-core \
  -i 10.144.144.3 \
  --network-name YOUR_NETWORK_NAME \
  --network-secret YOUR_STRONG_SECRET \
  -p tcp://SERVER_PUBLIC_IP:11010 \
  -p udp://SERVER_PUBLIC_IP:11010

Windows 下使用 easytier-core.exe，并以管理员身份启动终端。GUI 用户填写相同的网络名称、网络密码、虚拟 IP 和对等节点地址即可。

检查组网状态：

easytier-cli peer
easytier-cli route
ping 10.144.144.1

peer 输出中的 tunnel_proto、lat_ms 和 loss_rate 很重要：

p2p 或直连路径通常延迟最低。
通过服务器转发时，延迟大致由“本地到服务器”和“服务器到对端”两段路径共同决定。
丢包明显时，不要只盯着平均延迟；远程桌面的卡顿往往先由抖动和丢包触发。

四、部署 RustDesk Server OSS

在服务器上创建 RustDesk 工作目录：

sudo mkdir -p /opt/rustdesk/data
cd /opt/rustdesk
sudo nano compose.yml

写入：

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbs
    command: hbbs -r 10.144.144.1:21117
    volumes:
      - ./data:/root
    network_mode: host
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbr
    command: hbbr
    volumes:
      - ./data:/root
    network_mode: host
    restart: unless-stopped

其中：

hbbs 默认使用 21116 提供 ID 注册和连接服务，并使用 21115/TCP 进行 NAT 类型测试。
hbbr 默认使用 21117/TCP 提供中继服务。
-r 10.144.144.1:21117 明确告诉客户端中继服务位于服务器的 EasyTier 虚拟 IP。
./data:/root 用于持久化服务器密钥和数据库，迁移或备份时不能漏掉。

启动：

sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --tail=100 hbbs hbbr

读取 RustDesk 公钥：

sudo cat /opt/rustdesk/data/id_ed25519.pub

id_ed25519.pub 可以填写到客户端；同目录下的私钥绝不能公开。

如果使用 UFW，并且只允许 EasyTier 网段访问 RustDesk：

sudo ufw allow from 10.144.144.0/24 to any port 21115:21117 proto tcp
sudo ufw allow from 10.144.144.0/24 to any port 21116 proto udp

云安全组仍然只开放 11010/TCP 和 11010/UDP。RustDesk 官方还列出了 21118、21119 两个 Web 客户端端口；本文不使用 Web 客户端，因此保持关闭。

五、配置 RustDesk 客户端

远控端和被控端都要先接入 EasyTier，并确认能够访问 10.144.144.1。然后打开 RustDesk：

进入“设置”→“网络”。
解锁网络设置。
ID Server 填写 10.144.144.1:21116。
Relay Server 填写 10.144.144.1:21117。
Key 填写 id_ed25519.pub 的完整内容。
API Server 留空；开源版不需要它。
保存后检查客户端底部是否显示“就绪”。

RustDesk 官方说明中继地址通常可以由客户端推断，但这里显式填写，方便确认所有流量都使用预期的 EasyTier 地址。

接下来使用另一台设备的 RustDesk ID 发起连接。测试时同时观察：

easytier-cli peer
sudo docker compose -f /opt/rustdesk/compose.yml logs -f hbbs hbbr

如果 RustDesk 日志显示使用了 hbbr，说明本次连接经过 RustDesk 中继；如果双方建立了直连，则服务器主要负责 ID 和连接协调。

六、没有公网 IP 时，用 Sakura Frp 暴露 EasyTier

如果没有这台带独立公网 IP 的服务器，原来的 Sakura Frp 方案仍然能用，而且没有必要把 RustDesk 的每个端口都单独映射出去。只暴露 EasyTier 入口，再让 RustDesk 走虚拟网络即可。

在 Sakura Frp 面板中创建 TCP 隧道：

配置项	值
隧道类型	TCP
本地 IP	`127.0.0.1`
本地端口	`11010`
节点	优先选择距离双方近、跨网表现稳定的节点
远程端口	使用平台分配或允许设置的端口

在运行 EasyTier 固定节点的设备上启动 Sakura Frp 客户端。可以使用官方启动器，也可以按面板给出的隧道 ID 启动：

./frpc -f 'YOUR_ACCESS_TOKEN:YOUR_TUNNEL_ID'

其他设备把 EasyTier 的对等节点地址改为：

easytier-core \
  -i 10.144.144.2 \
  --network-name YOUR_NETWORK_NAME \
  --network-secret YOUR_STRONG_SECRET \
  -p tcp://SAKURA_NODE_HOST:REMOTE_PORT

需要尝试 UDP 时，再单独创建一条指向本地 11010/UDP 的 UDP 隧道，并增加一个 udp:// 对等节点地址。TCP 路径通常更容易建立，但遇到丢包时可能产生队头阻塞；UDP 的实时性可能更好，实际效果必须按线路测试。

Sakura Frp 的“端口导出”功能还会尝试 NAT 打洞，但官方文档也明确提示：NAT 类型不合适时很可能不可用。它可以作为优化项，不能代替稳定的中转路径。

七、延迟不理想时怎么排查

1. 先测基础网络

ping SERVER_PUBLIC_IP
ping 10.144.144.1

比较公网 IP 和 EasyTier 虚拟 IP 的延迟与丢包。如果虚拟网络明显更差，先检查 EasyTier 实际选择的协议和路径。

2. 确认是否发生了双重中转

最差的情况可能是：

远控端 → EasyTier 中转 → 被控端 → RustDesk 中继 → 远控端

EasyTier 和 RustDesk 都可能在直连失败时启用中继。先通过 easytier-cli peer 判断 EasyTier 是否直连，再看 hbbr 日志确认 RustDesk 是否使用中继。能直连时不要强制所有流量经过 hbbr。

3. 选择更合适的节点地域

中转服务器不一定离其中一方越近越好。双方跨运营商时，应分别测试到服务器的延迟、抖动和晚高峰丢包，选择总路径更均衡的地域。

4. 调整 RustDesk 画质

网络路径优化后，编码参数仍会影响体验。弱网下适当降低分辨率、帧率和图像质量，往往比盲目追求高码率更稳定。

5. 检查服务器资源和流量

docker stats
ip -s link
df -h

2 核 2 GiB 对少量个人连接通常够用，但同时中继多路高分辨率画面时，带宽、CPU 和流量配额都可能成为瓶颈。

八、安全和维护

EasyTier 网络名称不要使用常见词，网络密码使用随机长字符串。
不要公开 Sakura Frp 访问密钥、隧道 ID、RustDesk 私钥或真实服务器管理端口。
RustDesk 的 id_ed25519.pub 是公钥，可以分发；id_ed25519 是私钥，必须妥善备份并限制权限。
不使用 RustDesk Web 客户端时，不开放 21118 和 21119。
定期备份 /opt/rustdesk/data 和两份 Compose 配置。
升级前记录当前镜像版本，先拉取镜像并查看变更，再执行 docker compose up -d。
云服务器有独立公网 IP 不代表所有端口都应该暴露；能只通过 EasyTier 访问的服务，就不要直接开放到公网。

最后

这次折腾的起点只是“向日葵太卡了”，最后却把以前为游戏联机准备的 EasyTier、Sakura Frp 和现在的 RustDesk 串成了一套完整方案。

没有公网 IP 时，Sakura Frp 可以帮助暴露 EasyTier 入口；有独立公网 IP 后，云服务器可以直接成为固定组网节点，同时承载 RustDesk 的 ID 和中继服务。整个方案并不能保证任何网络下都获得最低延迟，但它把连接路径、服务器位置和带宽控制权拿回了自己手里，后续出现问题也有明确的排查方向。