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库来建立和管理连接。这不是简单的执行远程命令而是构建了一个完整的、会话复用的安全通道。连接建立流程凭证验证当你在设备卡片上配置 SSH 用户和密钥或密码后FlyMode 会尝试建立连接。密钥认证是推荐方式它会在后台调用系统 SSH Agent如果可用或直接读取密钥文件。会话池管理为了提高效率FlyMode 会为每个受信任的设备维护一个 SSH 会话池。当需要进行笔记同步或文件传输时它会从池中取出一个空闲会话而不是每次都重新进行完整的 SSH 握手。这大大降低了频繁操作的延迟。通道复用在一个 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 哈希值用于检测内容是否真的发生了改变。同步引擎工作原理增量扫描同步触发时手动或定时FlyMode 会扫描本地数据库找出所有updated_at晚于上次同步时间的笔记。差异对比对于每一条待同步的笔记计算其当前的sync_hash并与上次同步时记录的哈希值对比。只有哈希值发生变化的笔记才会被标记为“需要同步”。这个设计非常巧妙避免了因打开笔记但未修改而触发的无效同步。冲突解决Last-Write-Wins这是分布式系统中最经典的策略。当两个设备几乎同时修改了同一笔记时会发生冲突。FlyMode 的比较依据是updated_at时间戳时间更晚的修改将覆盖较早的。对于绝大多数个人使用场景如便签、想法记录这种策略简单有效。如果你需要更复杂的合并策略如 Git Merge目前需要手动处理。传输与合并通过 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 会执行一系列精密操作建立 SSH PTY伪终端会话这是实现交互式终端的基础。自动定位openclaw客户端二进制文件。它并非简单依赖$PATH而是执行了一个复合查找策略先尝试which openclaw如果失败则在一些常见目录如/usr/local/bin,/usr/bin,~/.local/bin中进行find查找并智能地追踪符号链接。设置正确的终端环境变量特别是LANG和LC_ALL确保 OpenClaw 的 TUI 界面能正确显示 UTF-8 字符这对任何 TUI 应用都至关重要。最终在建立的 PTY 中启动openclaw命令并将终端输出通过 WebSocket 实时推送到前端的 xterm.js 实例进行渲染。多标签终端管理 你可以同时连接到多个设备的 OpenClaw每个连接都以独立标签页的形式存在。这些标签页是“持久化”的——即使你切换到其他功能标签如笔记SSH 会话和 OpenClaw 进程依然在后台运行不会断开。这就像浏览器一样让你可以在不同的节点间快速切换上下文。2.3 无线设备调度与快速操作这个功能模块将系统级的控制能力带到了图形界面中特别适合用于创建自动化规则。调度规则引擎 规则在底层是通过一个轻量级的、内存中的调度器来管理的。它不依赖系统的cron而是使用 Rust 的tokio异步运行时来管理定时任务。当你创建一条“每天 23:00 关闭 WiFi07: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这行命令后会发生以下事情脚本会检测你的系统架构x86_64 或 arm64和发行版Ubuntu/Debian, Fedora, Arch 等。从 GitHub Releases 下载对应系统的最新版预编译包。对于大多数 Linux 系统默认下载的是.AppImage格式。将 AppImage 文件放置到~/.local/bin/目录下并赋予可执行权限。尝试为你安装并启动 SSH 服务openssh-server。这是 FlyMode P2P 功能的基础。可选地它会询问你是否将~/.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 提供了两种发现机制Tailscale 自动发现跨网络首选如果两台设备都安装了 Tailscale 并登录了同一账户那么在 FlyMode 的“设备”标签页点击“发现 Tailscale 节点”对方的机器名和 Tailscale IP 会立刻出现。这背后是 FlyMode 调用了tailscale status --json命令并解析了其输出。手动添加局域网或已知 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 网络就已经搭建好了。接下来让我们逐一验证核心功能并分享一些调优技巧。笔记同步测试在 Device-A 的“笔记”标签页创建一条新笔记填写内容选择颜色和分类。点击顶部的“立即同步”按钮或者等待自动同步默认间隔可设置。切换到 Device-B查看笔记是否出现。首次同步可能需要几秒钟。在 Device-B 上修改这条笔记然后在 Device-A 上再次同步观察修改是否被同步过来并遵循“后修改者胜”的规则。文件传输测试在 Device-A 上进入“传输”标签页在左侧选择 Device-B 作为目标。点击“上传”从本地选择一个文件。你会看到远程文件浏览器的界面选择目标目录如~/Downloads。传输开始后下方会有进度条、速度和百分比显示。可以同时队列多个文件。在 Device-B 上进入“传输”标签页选择 Device-A 作为目标尝试下载一个文件回来体验远程文件浏览。OpenClaw 管理测试如果你有部署确保 Device-B 上正在运行openclaw-gateway服务。在 Device-A 的设备列表中Device-B 的卡片上应该会出现一个终端图标_可能需要等待最多2分钟的自动发现周期。点击该图标一个终端标签页会打开。如果一切顺利你应该直接看到了 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”的动作为例数据在架构中的流动如下前端触发用户在 UI 点击“同步”按钮触发一个 Preact 组件中的事件。IPC 调用前端通过 Tauri 的invoke函数调用一个注册好的 Rust 命令例如sync_notes_to_peer并传入目标设备 ID。后端路由Rust 后端收到命令路由到sync模块的处理函数。业务逻辑 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模块接口将数据合并入本地数据库。结果回传设备 B 的同步脚本执行完毕后将结果成功/失败、冲突列表等通过 SSH 通道传回设备 A 的后端。前端更新设备 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 userdevice-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 提供的价值远超其学习成本。它的开源本质也意味着如果你对某个功能有特别的需求完全可以自己动手或向社区提出这也是自托管软件的魅力所在。