为什么 Clash Verge Rev 选择了 Tauri

📜 历史背景:从原版 Clash Verge 到 Rev

Clash Verge 最初的版本是基于 Electron 构建的。如果你用过早期版本,一定对那个“安装包 150MB、启动要等七八秒、内存经常跑到 400MB+”的体验印象深刻。不是说 Electron 不好,而是对于一款需要常驻后台、时刻监听系统网络的代理工具来说,资源开销实在有点过分。每次切节点、开 TUN 模式,风扇呼呼转,感觉像在运行一个完整的浏览器。

后来社区 fork 出 Clash Verge Rev,内核换成了更激进的 Mihomo (Clash Meta),也顺带开始重新审视整个桌面框架的选择。经过几次讨论、POC 和实际测试,团队最终拍板用 Tauri 重写了客户端。这个过程并不轻松,但如今回头看,这个决定直接奠定了 Rev 版本“轻量、稳定、跨平台统一”的体验基础。如果你好奇配置这一整套系统的细节,可以翻一下 配置教程,里面很多设计都和 Tauri 的能力有关。

🤔 第一印象:Electron 的“重”与代理客户端的矛盾

在聊 Tauri 之前,先说说 Electron 为什么不适合代理客户端。Electron 本质上是把一个完整的 Chromium 浏览器和 Node.js 运行时打包进了你的应用。好处是可以用 Web 技术写界面,跨平台也容易;坏处也显而易见:每个 Electron 应用都是一个独立的浏览器实例,内存占用高、磁盘空间大、冷启动慢。对于偶尔开一下的笔记软件或许还能忍受,但对于开机自启动、需要 24 小时运行的系统代理来说,完全是资源浪费。

记得有一次我在一台 4GB 内存的老笔记本上同时开着 Clash Verge 和 VS Code,系统直接卡到任务栏都点不动。打开任务管理器一看,两个 Electron 进程加起来吃了快 1.2GB 内存。这对于一个“应该隐藏在托盘里安静工作”的工具来说,是完全不可接受的。而且 Electron 的自动更新、Chromium 安全漏洞修复频率,也给维护带来了额外的负担。社区里每隔一段时间就有人提 issue 抱怨内存泄漏,查到最后十有八九是 Chromium 的锅。

🧬 Tauri 是什么?为什么它吸引了我们

Tauri 是近年来崛起的跨平台桌面框架,它的核心思路是:用系统的 WebView 替代打包 Chromium,用 Rust 替代 Node.js 处理后端逻辑。这意味着应用不再需要自己带一个浏览器内核,而是直接调用操作系统内置的 WebView——Windows 用 WebView2 (Edge 内核),macOS 用 WKWebView,Linux 用 WebKitGTK。这样一来,安装包的体积一下子从 100MB+ 降到了 10MB 以内,内存占用也大幅下降。

更重要的是,后端部分用 Rust 编写,这让它可以和 Mihomo 内核无缝对接。Mihomo 本身就是 Rust 项目,Clash Verge Rev 作为它的官方 GUI,前后端都用 Rust 意味着可以共享很多系统底层调用。比如 TUN 模式 中创建虚拟网卡、修改路由表的操作,以前需要 Electron 通过 Node.js 调用系统命令或原生模块,现在 Tauri 可以直接在 Rust 层完成,速度更快,出错概率更低。

💡 一句话总结: Tauri 让代理客户端从“拖着一个浏览器的胖子”变成了“系统原生的轻量工具”。如果你对 Rust 还不熟悉,可以先看看 Mihomo 插件开发指南,里面有一些 Rust 生态的介绍。

⚡ 实测对比:启动速度、内存占用与包体积

口说无凭,我们实际测试了同一个功能级别的 Electron 旧版和 Tauri 新版在相同硬件上的表现。测试环境:Windows 11 23H2,Intel i5-1135G7,16GB DDR4,SSD。

指标Electron (旧版 Clash Verge)Tauri (Clash Verge Rev)
安装包大小~148 MB (.exe)~9.2 MB (.msi)
安装后磁盘占用~380 MB~45 MB
冷启动时间7.2 秒2.1 秒
托盘常驻内存~210 MB~38 MB
TUN 模式活跃内存~350 MB (持续增长)~85 MB (稳定)
CPU 占用 (闲置)0.5% - 1.2%0.1% - 0.3%

这些数字对老电脑尤其友好。我有一台用来做软路由的 J4125 工控机,4GB 内存,Electron 版根本跑不动,Tauri 版却能在上面稳定运行 DNS 服务规则引擎,甚至还能同时做局域网共享网关(参考 Ubuntu 部署教程 的思路)。内存占用低了,系统的 OOM Killer 也不会三天两头把 Clash 进程杀掉,这对需要长期运行的服务器环境来说是致命的改进。

还有一个细节是启动时的白屏问题。Electron 版启动时总会短暂显示一个空白窗口,因为 Chromium 需要加载。Tauri 利用系统 WebView,窗口几乎是瞬间出现,而且可以自定义启动背景图,用户体验好了一大截。

🔒 安全模型:从 Chrome 沙箱到 Rust 后端

代理客户端是网络流量的守门人,安全性的重要程度不言而喻。Electron 依赖 Chromium 的沙箱机制,理论上安全,但实际上 Chromium 的漏洞修补是一个永无止境的过程。每次 Chromium 发现新 CVE,Electron 都要等上游合并,再发布新版本,应用方再跟着更新。这中间的延迟可能长达数周,期间你的客户端可能暴露在已知漏洞下。

Tauri 的安全模型完全不同。它的核心是用 Rust 写的,天然规避了内存安全漏洞(缓冲区溢出、use-after-free 等)。前端和 Rust 后端的通信通过 Tauri 的 IPC 机制,每个 API 调用都需要显式声明权限。比如前端要执行 shell 命令或者读写文件,必须在 tauri.conf.json 里明确授权。这意味着即使前端被攻击者注入恶意脚本,能造成的损害也极其有限——它无法随意调用系统命令、读取配置文件或修改网络设置。

这对代理客户端尤其重要,因为我们经常需要导入第三方订阅。如果前端存在 XSS 漏洞,在 Electron 里可能被用来执行任意 Node.js 代码,读取你的节点密码。在 Tauri 里,这些敏感操作必须通过 Rust 后端完成,前端只能发送请求并等待结果。关于如何安全地管理订阅,可以参考 导入订阅指南,里面提到了加密备份的重要性。

⚠️ 安全提醒: 无论用什么框架,请确保从官方 GitHub 或 客户端下载 页面获取安装包。第三方修改版可能在内核或前端植入恶意代码。

🛠️ 开发体验:React 前端 + Rust 后端的化学反应

从开发者的角度看,Tauri 的选择也带来了很多便利。Clash Verge Rev 的前端仍然使用 React(与 Electron 时代保持一致),这让现有的 Web 开发者可以无缝切换。后端逻辑从 Node.js 迁到 Rust,虽然门槛高了一点,但换来的是性能和安全的巨大提升。

一个典型的例子是配置文件的解析和校验。YAML 配置可能包含几百个节点和上千条规则,在 Node.js 里解析需要数秒,还容易因为内存占用过高导致主线程阻塞。Rust 的 serde_yaml 库是编译时优化的,解析同样的配置只需要几十毫秒,而且内存分配更加可控。用户在 配置页面 里编辑、重载配置时,能明显感觉到 Tauri 版的响应更加迅速,不再有“保存后等两秒才生效”的延迟。

另一个让开发者开心的点是调试体验。Electron 时代需要同时看 Chromium DevTools 和 Node.js 的输出,日志混在一起,出了问题很难定位。Tauri 将前端和后端日志分离,Rust 后端用 tracing 库生成结构化日志,可以按级别过滤,也能直接输出到文件。如果你尝试过自己编写 Mihomo 插件,会发现这套日志系统和内核的日志风格完全一致,排错效率高了不少。

🌍 跨平台一致性:Windows、macOS、Linux 的真实表现

Electron 的跨平台是靠 Chromium 的一致性来保证的,这在大多数情况下没问题,但一旦涉及系统原生功能(如托盘菜单、系统通知、自动启动),不同平台就会暴露出各种兼容问题。macOS 上的托盘图标模糊、Linux 上通知不弹、Windows 上自动启动注册失败……这些现象在 Electron 生态里非常常见。

Tauri 因为使用系统原生 WebView,所以每个平台的渲染效果与系统内置浏览器完全一致。Windows 上用的是 Edge 内核,支持最新的 CSS 特性;macOS 上是 Safari 内核,滚动动画更流畅;Linux 上是 WebKitGTK,虽然性能稍弱,但在轻量级 GUI 场景下完全够用。而且 Tauri 的 Rust 后端可以针对不同平台写条件编译,比如 Windows 上用 winapi 直接操作注册表实现开机自启,macOS 上则通过 launchd,完全不需要前端关心。这种底层能力在 TUN 模式 的虚拟网卡创建中尤其关键——Windows WFP 和 macOS Network Extension 的实现差异巨大,Rust 的条件编译让同一套代码可以优雅地处理这些差异,而不是像 Electron 那样需要为每个平台写不同的 Node 原生模块。

👥 社区考量与生态成熟度

选择框架还有一个现实问题:社区活跃度和生态工具。Electron 的生态无疑是庞大的,但 Tauri 的社区在近两年里发展极快。Clash Verge Rev 刚立项时,Tauri 才 1.0 不久,有些功能确实不够完善——比如自动更新服务需要自己搭建,WebView 的某些边缘 API 还没覆盖。但到了 2026 年,Tauri 2.0 已经非常成熟,官方提供了完整的自动更新、插件市场、以及大量的 Rust crate 支持。

更重要的是,代理工具的用户群体中,开发者占比很高。很多人本身就熟悉 Rust 或愿意学习 Rust。当用户知道 Clash Verge Rev 是用 Rust 写的,他们对性能和安全性的信任度会自然提高。在 GitHub Issues 里,经常能看到社区贡献者提交 PR 修复 Rust 后端的 bug,这在 Electron 时代是很少见的——毕竟很少有人愿意去翻 Chromium 的源码。

如果你想参与开发,或者只是想看看源码,可以访问 GitHub 仓库。Wiki 里也有不少关于 Tauri 迁移的技术文档,地址是 这里

🏁 总结:轻量代理客户端的未来

回过头看,从 Electron 到 Tauri 的迁移,不仅仅是一次技术栈的更替,更是对“代理客户端应该是什么样子”的重新定义。它不应该是一个臃肿的浏览器附属品,而应该是一个贴近系统、安静运行、资源消耗极低的后台服务。Tauri 让这个理想成为了现实。

当然,没有银弹。Tauri 的 WebView 在某些 Linux 发行版上仍然存在兼容性问题(比如 Deepin 的自研内核),前端开发中偶尔也会遇到系统 WebView 版本不一致导致的样式差异。但相比于 Electron 的“重”,这些都是可以接受的小麻烦。更何况,社区已经在积极解决这些问题,每次更新都在变好。

如果你还在犹豫要不要从旧版升级到 Rev,或者正在考虑为自己的项目选择桌面框架,希望这篇文章能给你一些参考。轻量、高性能、安全,这三个词就是 Clash Verge Rev 选择 Tauri 的全部理由。最后,如果你想试试看这个轻量版的真正实力,不妨从 下载页面 获取最新版本,搭配 配置教程 一起使用,应该会给你带来惊喜。

📖 继续阅读