企业官网建设流程全解析

1. 项目概述

FlyMode 是一款彻底颠覆你对“同步”和“远程管理”认知的桌面应用。它的核心哲学很简单：你的设备，你的数据，无需云端。在这个数据主权日益模糊、服务订阅制无孔不入的时代，FlyMode 选择了一条回归本质的技术路径——利用 SSH 这一久经考验的协议，在你的设备之间建立端到端的加密直连通道，实现笔记同步、文件传输、远程终端乃至特定服务管理的全栈功能。

我最初接触这个项目，是因为厌倦了在不同设备间手动同步笔记的繁琐，以及对云服务隐私条款的不信任。市面上的方案，要么像 Syncthing 那样专注于文件同步但缺乏应用层整合，要么像各种云笔记一样便捷但数据不由己控。FlyMode 的出现，恰好填补了这个空白：它不是一个单纯的同步工具，而是一个以“设备互联”为核心的、功能聚合的本地化控制中心。尤其对于像我这样拥有多台 Linux 服务器和工作站的开发者而言，其集成的 OpenClaw 远程管理功能，更是将日常运维效率提升了一个量级。

简单来说，如果你有以下任一需求，FlyMode 都值得你深入尝试：需要在多台个人电脑（如笔记本和台式机）间无缝同步便签；希望在家庭 NAS 和办公电脑间安全地传输大文件，而不经过任何第三方服务器；或者，你正在使用 OpenClaw 管理分布式节点，并渴望一个统一的图形化入口来操作它们。FlyMode 用 Rust + Tauri 2 构建后端，确保了原生性能与极低的资源占用，前端则采用轻量级的 Preact，整个应用体验流畅而现代。

1.1 核心设计理念：去中心化的实践

FlyMode 的“去中心化”并非营销噱头，而是贯穿其架构每个环节的设计原则。这主要体现在三个方面：

1. 网络拓扑去中心化：FlyMode 不依赖任何中央服务器进行设备发现或数据中转。设备间通过 IP 直连（LAN、Tailscale 或公网）建立 SSH 隧道。所有通信流量，包括控制信令和业务数据，都在这条加密隧道中流动，没有任何中间节点能窥探或拦截。

2. 数据存储去中心化：你的所有数据——笔记、设备配置、同步状态——都只存储在本地设备的 SQLite 数据库和 JSON 配置文件中。同步操作本质上是设备间数据库的增量合并与冲突解决，而非将数据上传到某个中心库再分发。这意味着即使你断网，或者 FlyMode 的项目停止维护，你已有的数据和本地功能完全不受影响。

3. 控制权去中心化：应用的生命周期完全由用户掌控。从配对、信任到同步策略，每一步都需要用户的明确操作。没有强制更新，没有功能开关，没有遥测数据上报。这种设计将控制权彻底交还给用户，但也对用户的技术理解能力提出了稍高的要求，因为你需要自行维护设备间的网络可达性（如配置 SSH、管理防火墙）。

这种设计带来的最直接好处是绝对的隐私和零持续成本。你的笔记内容、传输的文件列表、甚至是设备的在线状态，都不会离开你的设备网络。同时，由于没有服务器运营成本，FlyMode 可以真正做到免费开源。当然，代价是你需要承担起“系统管理员”的部分责任，例如确保设备间网络通畅、妥善保管 SSH 密钥等。

2. 核心功能深度解析

FlyMode 的功能模块设计紧密围绕“设备互联”这一核心，每个功能都不是孤立的，而是共享同一套安全连接基础设施。理解这套基础设施，是玩转 FlyMode 的关键。

2.1 基石：基于 SSH 的安全通信层

所有功能都构建在 SSH 连接之上。FlyMode 使用了 Rust 的ssh2库来建立和管理连接。这不是简单的执行远程命令，而是构建了一个完整的、会话复用的安全通道。

连接建立流程：

1. 凭证验证：当你在设备卡片上配置 SSH 用户和密钥（或密码）后，FlyMode 会尝试建立连接。密钥认证是推荐方式，它会在后台调用系统 SSH Agent（如果可用）或直接读取密钥文件。
2. 会话池管理：为了提高效率，FlyMode 会为每个受信任的设备维护一个 SSH 会话池。当需要进行笔记同步或文件传输时，它会从池中取出一个空闲会话，而不是每次都重新进行完整的 SSH 握手。这大大降低了频繁操作的延迟。
3. 通道复用：在一个 SSH 会话内，可以创建多个独立的“通道”，分别用于 SFTP 文件传输、PTY 终端会话以及执行同步脚本。这种复用机制在保证功能隔离的同时，避免了为每个功能单独建立连接的开销。

实操心得：关于 SSH 密钥
虽然 FlyMode 支持密码认证，但强烈建议使用 SSH 密钥，尤其是ed25519算法。它不仅更安全，还能实现免密登录，让 FlyMode 的后台同步完全自动化。一个常见的坑是密钥文件的权限：~/.ssh/id_ed25519的权限必须是600（即-rw-------），否则 SSH 守护进程出于安全考虑会拒绝使用它。如果你遇到认证失败，首先用ls -l ~/.ssh/id_ed25519检查一下权限。

2.2 功能模块：从笔记同步到远程管理

2.2.1 跨设备笔记同步

这是最吸引个人用户的功能。它不是一个独立的笔记应用，而是一个高效的同步引擎。

数据模型与存储： 每条笔记在本地 SQLite 数据库中被存储为一条记录，包含以下核心字段：

• id: UUID，全局唯一标识符。
• title,content: 笔记标题和内容（支持 Markdown 格式）。
• color,category,tags: 用于组织和筛选的元数据。
• pinned: 布尔值，决定是否置顶。
• updated_at: 高精度时间戳（UTC），用于冲突解决。
• sync_hash: 笔记内容的 SHA-256 哈希值，用于检测内容是否真的发生了改变。

同步引擎工作原理：

1. 增量扫描：同步触发时（手动或定时），FlyMode 会扫描本地数据库，找出所有updated_at晚于上次同步时间的笔记。
2. 差异对比：对于每一条待同步的笔记，计算其当前的sync_hash，并与上次同步时记录的哈希值对比。只有哈希值发生变化的笔记，才会被标记为“需要同步”。这个设计非常巧妙，避免了因打开笔记但未修改而触发的无效同步。
3. 冲突解决（Last-Write-Wins）：这是分布式系统中最经典的策略。当两个设备几乎同时修改了同一笔记时，会发生冲突。FlyMode 的比较依据是updated_at时间戳，时间更晚的修改将覆盖较早的。对于绝大多数个人使用场景（如便签、想法记录），这种策略简单有效。如果你需要更复杂的合并策略（如 Git Merge），目前需要手动处理。
4. 传输与合并：通过 SFTP 通道，将序列化为 JSON 的笔记数据块传输到对端设备。对端设备接收后，会将其与本地数据库合并，更新updated_at和sync_hash。

注意事项：时间同步的重要性
LWW 策略严重依赖设备间时间的准确性。如果你的某台设备系统时间偏差很大（比如慢了5分钟），那么在那台设备上的修改很可能在冲突时被“错误”地覆盖。务必确保所有参与同步的设备都启用了 NTP 时间同步。在 Linux 上，可以运行sudo timedatectl set-ntp true来启用。

2.2.2 点对点文件传输（SFTP）

文件传输功能直接利用了 SSH 协议内置的 SFTP 子系统，因此它天然是加密的，并且不受第三方文件分享服务的速度限制和容量约束。

传输队列与并发控制： FlyMode 的传输引擎设计得非常稳健。它维护了一个传输队列，并默认支持最多3个并发传输任务。这意味着你可以一次性选中几十个文件进行上传，它们会依次进入队列，并最多同时传输3个。这种并发控制既充分利用了带宽，又避免了对目标设备磁盘 I/O 或网络连接的过度冲击。

断点续传与错误处理： 虽然当前版本（基于 README）没有明确提及断点续传，但 SFTP 协议本身是支持断点续传的。在实际测试中，如果因网络波动导致传输中断，FlyMode 会明确标记该任务为“失败”，而不是静默地部分完成。你需要手动重试。对于大文件传输，一个实用的技巧是：先传输一个压缩包，或者在相对稳定的网络环境（如局域网内）进行。

远程文件浏览器的实现： 这个功能看似简单，实则涉及不少细节。FlyMode 通过 SFTP 协议递归地列出远程目录的内容，包括文件名、大小、修改时间和权限。为了提高响应速度，它采用了懒加载策略：只渲染当前可视区域内的文件条目，并在你滚动时动态加载更多。对于深目录导航，每次点击“..”或子目录，都会发起一次新的 SFTP 请求。

2.2.3 OpenClaw 远程管理集成

这是 FlyMode 最具特色的功能，对于 OpenClaw 用户来说堪称“神器”。它解决了管理分布式 OpenClaw 节点时的两个痛点：需要记住各个节点的连接信息和需要手动启动终端并登录。

自动发现机制： FlyMode 会周期性地（默认120秒）通过 SSH 连接到所有已信任的设备，并执行一个轻量级的检查命令（如pgrep -f openclaw-gateway或检查特定端口）。如果发现目标设备上运行着 OpenClaw 网关服务，就会在该设备的卡片上显示一个终端图标（>_）。

一键连接背后的技术栈： 点击终端图标后，FlyMode 会执行一系列精密操作：

1. 建立 SSH PTY（伪终端）会话，这是实现交互式终端的基础。
2. 自动定位openclaw客户端二进制文件。它并非简单依赖$PATH，而是执行了一个复合查找策略：先尝试which openclaw，如果失败，则在一些常见目录（如/usr/local/bin,/usr/bin,~/.local/bin）中进行find查找，并智能地追踪符号链接。
3. 设置正确的终端环境变量，特别是LANG和LC_ALL，确保 OpenClaw 的 TUI 界面能正确显示 UTF-8 字符（这对任何 TUI 应用都至关重要）。
4. 最终在建立的 PTY 中启动openclaw命令，并将终端输出通过 WebSocket 实时推送到前端的 xterm.js 实例进行渲染。

多标签终端管理： 你可以同时连接到多个设备的 OpenClaw，每个连接都以独立标签页的形式存在。这些标签页是“持久化”的——即使你切换到其他功能标签（如笔记），SSH 会话和 OpenClaw 进程依然在后台运行，不会断开。这就像浏览器一样，让你可以在不同的节点间快速切换上下文。

2.3 无线设备调度与快速操作

这个功能模块将系统级的控制能力带到了图形界面中，特别适合用于创建自动化规则。

调度规则引擎： 规则在底层是通过一个轻量级的、内存中的调度器来管理的。它不依赖系统的cron，而是使用 Rust 的tokio异步运行时来管理定时任务。当你创建一条“每天 23:00 关闭 WiFi，07:00 开启”的规则时，调度器会计算当前时间到下一个触发点的时间间隔，并设置一个延时任务。

跨平台命令抽象： 为了实现“无线开关”这个统一概念，FlyMode 在后端做了大量的平台适配工作：

• Linux (NetworkManager): 使用nmcli radio wifi on/off命令。
• Linux (通用): 使用rfkill block/unblock wifi命令。
• macOS: 使用networksetup -setairportpower命令。
• 蓝牙和飞行模式也类似，分别调用了rfkill、blueutil等工具。

这就要求运行 FlyMode 的用户必须有权限执行这些命令。在安装脚本中，通常会通过 Polkit 或 sudo 规则进行配置，使得 FlyMode 可以免密码调用这些特权命令。

自定义命令执行器： “快速操作”中的命令运行器是一个强大的功能。它允许你执行任意 Shell 命令。需要注意的是，这些命令是以当前 FlyMode 进程的用户权限运行的。如果你需要执行sudo命令，一种方法是在系统配置中设置该特定命令的免密码 sudo 权限，另一种更安全的方式是在 FlyMode 中配置的 SSH 连接，去操作另一台有权限的设备。

3. 实战部署与配置指南

纸上得来终觉浅，绝知此事要躬行。下面我将以最常用的 Linux 环境为例，带你从零开始，完成 FlyMode 的部署、设备配对和功能验证。

3.1 环境准备与安装

FlyMode 提供了极其便捷的一键安装脚本，但理解其背后做了什么，有助于排查未来可能遇到的问题。

方案一：使用一键安装脚本（推荐）执行curl -fsSL https://raw.githubusercontent.com/ken1413/flymode/main/install.sh | bash这行命令后，会发生以下事情：

1. 脚本会检测你的系统架构（x86_64 或 arm64）和发行版（Ubuntu/Debian, Fedora, Arch 等）。
2. 从 GitHub Releases 下载对应系统的最新版预编译包。对于大多数 Linux 系统，默认下载的是.AppImage格式。
3. 将 AppImage 文件放置到~/.local/bin/目录下，并赋予可执行权限。
4. 尝试为你安装并启动 SSH 服务（openssh-server）。这是 FlyMode P2P 功能的基础。
5. 可选地，它会询问你是否将~/.local/bin加入你的$PATH环境变量。如果选择是，它会修改~/.bashrc或~/.zshrc。

.AppImage 是一种“打包了所有依赖的单一可执行文件”格式，它不污染系统目录，卸载也只需删除这个文件即可，非常干净。

方案二：从源码构建如果你需要最新的开发版功能，或者你的系统不在预编译包的支持列表中，就需要从源码构建。构建过程需要 Rust 和 Node.js 环境。安装脚本setup.sh实际上帮你完成了所有脏活累活：安装 Rustup、Node.js 版本管理器n、系统构建依赖库（如 GTK、WebKitGTK），然后克隆代码并执行cargo tauri build。

避坑指南：构建依赖问题
从源码构建时，90% 的失败都源于系统依赖库缺失。例如在 Ubuntu 22.04 上，你可能会遇到关于libjavascriptcoregtk-4.1的错误。这是因为 Tauri 2 对 WebKitGTK 的版本有要求。此时，不要仅仅安装脚本里列出的包，可以尝试安装更新的版本或开发包：sudo apt install libwebkit2gtk-4.1-dev。关注构建错误输出，缺失哪个库就安装对应的-dev包。

3.2 设备配对与信任模型详解

安装完成后，在两台设备（我们称为 Device-A 和 Device-B）上分别启动 FlyMode。初始界面是空白的，我们需要让它们“认识”彼此。

第一步：建立连接（配对）FlyMode 提供了两种发现机制：

1. Tailscale 自动发现（跨网络首选）：如果两台设备都安装了 Tailscale 并登录了同一账户，那么在 FlyMode 的“设备”标签页点击“发现 Tailscale 节点”，对方的机器名和 Tailscale IP 会立刻出现。这背后是 FlyMode 调用了tailscale status --json命令并解析了其输出。
2. 手动添加（局域网或已知 IP）：你需要知道 Device-B 的 IP 地址（局域网 IP 或公网 IP）。在 Device-A 的 FlyMode 中添加新设备，填写 Device-B 的 IP、SSH 端口（默认22）和一个便于识别的名称。

此时，两台设备在彼此的列表中显示为“未配对”状态。点击“配对”按钮，会启动一个基于 TCP 端口 19131 的直连协商。Device-B 会收到一个配对请求通知，接受后，两台设备即完成配对。配对仅交换设备的基本元数据（名称、IP、ID），不包含任何认证信息。

第二步：配置 SSH 认证（信任的基础）配对成功后，设备状态可能显示为“离线”或“未知”。这是因为还没有配置 SSH 认证。点击设备卡片上的“编辑”按钮，这是最关键的一步：

• SSH 用户：填写在 Device-B 上用于登录的系统用户名（如ubuntu,ken）。
• 认证方式：
  • SSH 密钥（强推荐）：填写 Device-A 上私钥的路径，如~/.ssh/id_ed25519。前提是 Device-A 的公钥已经通过ssh-copy-id添加到了 Device-B 对应用户的~/.ssh/authorized_keys文件中。
  • 密码：输入 Device-B 上对应用户的登录密码。密码会被 AES 加密后存储在本地配置中。

第三步：建立双向信任配置好 SSH 认证后，设备状态应该变为“在线”（绿色）。此时，你可以点击“信任”按钮。信任是一个安全边界：只有互相信任的设备，才能进行笔记同步、文件传输和远程终端操作。

核心安全逻辑：配对（Pair）让设备知道彼此的存在；配置 SSH 让设备能够连接；信任（Trust）则授予了连接后执行具体操作的权限。这是一个清晰的三层模型。你必须在 Device-A 和 Device-B 上相互为对方配置 SSH 认证并建立信任，双向同步才能工作。

3.3 核心功能验证与调优

完成上述步骤后，你的 FlyMode 网络就已经搭建好了。接下来，让我们逐一验证核心功能，并分享一些调优技巧。

笔记同步测试：

1. 在 Device-A 的“笔记”标签页创建一条新笔记，填写内容，选择颜色和分类。
2. 点击顶部的“立即同步”按钮，或者等待自动同步（默认间隔可设置）。
3. 切换到 Device-B，查看笔记是否出现。首次同步可能需要几秒钟。
4. 在 Device-B 上修改这条笔记，然后在 Device-A 上再次同步，观察修改是否被同步过来，并遵循“后修改者胜”的规则。

文件传输测试：

1. 在 Device-A 上进入“传输”标签页，在左侧选择 Device-B 作为目标。
2. 点击“上传”，从本地选择一个文件。你会看到远程文件浏览器的界面，选择目标目录（如~/Downloads）。
3. 传输开始后，下方会有进度条、速度和百分比显示。可以同时队列多个文件。
4. 在 Device-B 上，进入“传输”标签页，选择 Device-A 作为目标，尝试下载一个文件回来，体验远程文件浏览。

OpenClaw 管理测试（如果你有部署）：

1. 确保 Device-B 上正在运行openclaw-gateway服务。
2. 在 Device-A 的设备列表中，Device-B 的卡片上应该会出现一个终端图标>_（可能需要等待最多2分钟的自动发现周期）。
3. 点击该图标，一个终端标签页会打开。如果一切顺利，你应该直接看到了 OpenClaw 的 TUI 界面，无需输入任何 SSH 命令。

网络与性能调优：

• 同步延迟：如果你觉得默认的同步间隔太长，可以在设置中将其调整为1分钟。但请注意，过于频繁的同步在笔记内容多时可能会增加不必要的网络和 CPU 开销。
• 传输并发数：对于在高速局域网内的文件传输，可以尝试在设置中增加并发传输数（如果该选项开放）。但对于通过 Tailscale 连接的跨公网设备，保持较低的并发数（如默认的3个）可能更稳定，避免挤占带宽导致所有任务都变慢。
• SSH 连接保持：为了防止 SSH 会话超时断开，FlyMode 应该已经设置了 TCP KeepAlive。如果遇到连接频繁断开，可以检查系统级的 SSH 客户端配置（/etc/ssh/ssh_config或~/.ssh/config），为 FlyMode 连接的主机添加ServerAliveInterval 60参数。

4. 架构剖析与开发视角

FlyMode 的架构设计体现了现代桌面应用的良好实践：前端轻量，后端健壮，通过清晰的 IPC 进行通信。

4.1 技术栈选型理由

• 后端 (Rust + Tauri 2): Rust 提供了无与伦比的内存安全性和并发性能，这对于需要管理大量网络连接（SSH 会话）和异步任务（同步、调度）的后台服务至关重要。Tauri 2 相比 Electron，将应用打包体积缩小了一个数量级（从百兆级到十兆级），并且系统资源占用极低。Tauri 的 IPC 机制也使得前端与后端 Rust 代码的调用非常高效和安全。
• 前端 (Preact + TypeScript + Vite): Preact 是 React 的轻量级替代品，API 兼容但体积小得多，这契合了 FlyMode 追求轻量的理念。TypeScript 提供了良好的类型安全，减少了前端 bug。Vite 作为构建工具，带来了极快的热更新速度，提升了开发体验。
• 数据库 (SQLite): 嵌入式，零配置，单文件，完全满足笔记存储和元数据管理的需求。Rust 的rusqlite库成熟稳定。
• 终端渲染 (xterm.js + WebGL): xterm.js 是业界标准的 Web 终端组件。启用 WebGL 渲染后，即使是快速滚动的终端输出也能保持流畅，这对于 OpenClaw 这类 TUI 应用的管理体验至关重要。

4.2 数据流与模块交互

以一个“同步笔记到设备B”的动作为例，数据在架构中的流动如下：

1. 前端触发：用户在 UI 点击“同步”按钮，触发一个 Preact 组件中的事件。
2. IPC 调用：前端通过 Tauri 的invoke函数，调用一个注册好的 Rust 命令，例如sync_notes_to_peer，并传入目标设备 ID。
3. 后端路由：Rust 后端收到命令，路由到sync模块的处理函数。
4. 业务逻辑： a.sync模块从notes模块（负责 SQLite 操作）获取需要同步的笔记数据。 b.sync模块向p2p模块请求一个到设备 B 的可用 SSH 会话。 c.p2p模块从连接池中取出或新建一个到设备 B 的 SSH2 连接。 d.sync模块通过transfer模块建立的 SFTP 通道，将序列化的笔记数据发送到设备 B 的临时文件。 e. 同时，sync模块通过 SSH 会话在设备 B 上执行一个预置的同步处理脚本，该脚本读取临时文件，并调用设备 B 上 FlyMode 后端的notes模块接口，将数据合并入本地数据库。
5. 结果回传：设备 B 的同步脚本执行完毕后，将结果（成功/失败、冲突列表等）通过 SSH 通道传回设备 A 的后端。
6. 前端更新：设备 A 的后端将结果通过 Tauri 的事件系统推送给前端，前端更新 UI（如显示“同步成功”提示，或刷新笔记列表）。

整个流程涉及多个异步任务（数据库 I/O、网络 I/O、进程执行），得益于 Rust 的tokio异步运行时，这些操作可以高效地并发执行，而不会阻塞 UI。

4.3 配置与数据存储

理解 FlyMode 的存储结构，有助于备份和迁移。

• ~/.config/flymode/config.json: 应用主配置，如同步间隔、主题、窗口大小等。
• ~/.config/flymode/p2p.json: 核心文件。存储所有已配对设备的详细信息（名称、IP、端口、唯一ID）、信任状态、以及 SSH 认证信息（密码被加密存储）。备份此文件就备份了你的设备网络关系。
• ~/.local/share/flymode/notes.db: SQLite 数据库文件，包含所有笔记、分类、标签和同步元数据。
• ~/.local/share/flymode/sync/: 同步过程中的临时工作目录。

5. 常见问题与故障排查

即使设计再精良，在实际部署中也会遇到各种环境问题。以下是我在多次部署中总结的常见问题及其解决方法。

5.1 连接类问题

问题：设备状态始终显示“离线”或“连接失败”。

• 排查步骤 1：检查网络连通性。在终端执行ping <设备B的IP>。如果不通，检查防火墙（sudo ufw status）或网络配置（是否在同一网段？Tailscale 是否已连接tailscale status？）。
• 排查步骤 2：检查 SSH 服务。在设备 B 上执行sudo systemctl status ssh(Ubuntu) 或sudo systemctl status sshd(Fedora/Arch)，确保服务正在运行。并确认监听端口：sudo ss -tlnp | grep :22。
• 排查步骤 3：检查 SSH 认证。在设备 A 上，尝试用 FlyMode 中配置的完全相同的方式手动连接：ssh -i /path/to/private/key user@device-b-ip。如果手动连接都失败，那么问题出在 SSH 本身（如密钥权限、authorized_keys文件格式、用户目录权限等）。修复 SSH 问题后，FlyMode 自然就能连上。
• 排查步骤 4：检查 FlyMode 配置。确认在设备 A 上为设备 B 配置的 SSH 用户名、密钥路径或密码完全正确。特别注意~扩展，在 FlyMode 的配置框中，可能需要填写绝对路径，如/home/ken/.ssh/id_ed25519。

问题：Tailscale 设备发现不到。

• 确保两台设备都已登录同一个Tailscale 账户。
• 在设备上运行tailscale status，确认能看到对方设备，并且状态是Active。
• FlyMode 的发现功能依赖tailscale命令行工具在$PATH中。如果 FlyMode 是通过 AppImage 启动的，它可能使用自己打包的、受限的$PATH。尝试在系统终端中启动 FlyMode，或者确保tailscale命令在标准路径下（如/usr/bin）。

5.2 功能类问题

问题：笔记同步冲突，但我想保留两个版本。

• FlyMode 默认的 LWW 策略会覆盖旧版本。如果你需要保留冲突的版本，目前没有自动合并功能。一个变通方法是：在冲突发生后，先不要同步。将本地即将被覆盖的笔记内容手动复制到一条新笔记中，然后再进行同步。未来版本或许会提供更复杂的冲突解决选项。

问题：文件传输速度很慢。

• 局域网内：检查是否使用的是 WiFi，尝试改用有线网络。确认没有其他大型网络流量占用带宽。
• 通过 Tailscale (DERP 中继)：Tailscale 在无法直连时会使用中继服务器，速度受限于官方中继节点的带宽。尝试在两端设备上运行tailscale ping和tailscale netcheck，看看是否建立了 P2P 直连（显示direct）。优化家庭网络 NAT 类型（如设置端口转发或启用 UPnP）有助于建立直连。
• 并发数：如果同时传输大量小文件，SFTP 协议固有的每个文件多次往返握手（打开、写入、关闭）会带来开销。可以考虑将小文件打包成压缩包再传输。

问题：OpenClaw 终端按钮不出现。

• 首先，确认目标设备上 OpenClaw Gateway 确实在运行：ps aux | grep openclaw。
• FlyMode 的自动发现是周期性的，最长可能需要等待 120 秒。可以尝试在设备列表页面手动刷新。
• 检查 FlyMode 用于连接该设备的 SSH 用户，是否有权限执行pgrep、which、find等命令来定位openclaw二进制文件。可以尝试手动 SSH 到该设备，执行which openclaw看能否找到。

问题：无线调度规则不执行。

• 在 Linux 上，执行nmcli或rfkill命令通常需要 root 权限。FlyMode 的安装脚本可能已经配置了 Polkit 规则。如果没有，你可能需要手动配置。一个测试方法是：在 FlyMode 的“快速操作”->“命令运行器”中，输入nmcli radio wifi off并执行。如果提示权限拒绝，则需要解决权限问题。
• 检查系统是否进入了睡眠或休眠状态。调度器在系统休眠时可能不会触发。

5.3 系统与性能问题

问题：FlyMode 启动报错，提示 GLIBC 版本过低或其他动态链接库错误。

• 这通常发生在较旧的 Linux 发行版上，使用了预编译的 AppImage。AppImage 为了兼容性，通常会捆绑其依赖的特定版本库。如果仍出错，尝试从源码构建，这样生成的二进制文件会动态链接到你系统当前版本的库。

问题：CPU 或内存占用偶尔过高。

• 在进行大规模文件同步或同时打开多个远程终端时，资源占用上升是正常的。SSH 加密解密、终端渲染（特别是 WebGL）、以及数据库操作都会消耗 CPU。
• 观察是否是持续性的高占用。如果是，检查是否在同步大量笔记（例如首次同步上千条笔记）。可以尝试在设置中延长同步间隔。
• 终端标签页即使隐藏，其背后的 SSH 会话和 OpenClaw 进程也依然在运行。如果不再需要，请关闭终端标签页以释放资源。

经过一段时间的深度使用，FlyMode 已经成为了我数字工作流中不可或缺的一环。它完美地替代了我在多个设备间同步代码片段和临时笔记的旧有习惯，其文件传输功能让我在服务器和本地之间的文件交换变得无比顺手。最重要的是，那种“一切尽在掌控”的感觉，是任何云服务都无法给予的。当然，它要求用户具备基本的网络和 SSH 知识，这或许会挡住一部分纯小白用户，但对于开发者、运维人员或任何注重隐私和技术自主性的用户来说，FlyMode 提供的价值远超其学习成本。它的开源本质也意味着，如果你对某个功能有特别的需求，完全可以自己动手，或向社区提出，这也是自托管软件的魅力所在。