Clash Verge Rev 版本更新追踪与新特性解读：从 fork 到主流的演进历程

一个开源项目为什么会从众多同类产品中脱颖而出？Clash Verge Rev 的发展路径挺有意思 —— 它并不是最早的，也不是唯一一个，但在几个关键选择上做对了事情。

这篇不讲具体怎么用，而是聊聊它的技术演进路线和版本特性变化，以及升级时需要注意的地方。

一、起点：为什么需要一个新的客户端

Clash for Windows 留下的空位

Clash for Windows（CFW）曾经是桌面端的事实标准，但它有两个逐渐凸显的问题：

第一，架构成本。 CFW 基于 Electron，每个运行实例相当于跑了一个完整的 Chromium。这在功能机上没什么感觉，但对一台同时开着浏览器、IDE、聊天软件的开发机来说，几百 MB 的常驻内存是实打实的负担。

第二，停止维护。 这是更致命的一点。项目停更意味着：

• 安全问题不会有补丁
• 新协议不再支持
• 与新版操作系统的兼容性问题只会累积

对于一款持有流量转发能力的软件，「不再更新」这四个字的分量比普通工具要重得多。

于是社区需要一个替代品。Clash Verge Rev 正是在这个空位上生长起来的。

二、关键决策：选择 Tauri 而不是 Electron

这是整个项目最重要的技术选择，也决定了它后续的大部分优势。

两种架构的本质区别

Electron：把浏览器打包进应用
┌────────────────────────┐
│  应用逻辑 + Chromium    │ ← 每个实例自带一份浏览器
└────────────────────────┘
体积大，占用高，但跨平台行为完全一致

Tauri：调用系统自带的 WebView
┌────────────────────────┐
│  应用逻辑 + 系统 WebView │ ← 复用系统组件
└────────────────────────┘
体积小，占用低，行为可能因系统而异

实际差距

安装包体积相差近十倍，常驻内存相差三倍左右 —— 这不是边际改进，是量级差异。

代价是什么

Tauri 并非没有成本。它依赖系统 WebView 组件，因此：

• Windows 上需要 WebView2 运行库
• Linux 上需要 WebKit2GTK
• 不同系统版本下界面渲染可能有细微差异

这也是我们在安装教程里反复强调「先装运行库」的原因。它把一部分复杂度从应用转移到了系统依赖上 —— 换来的是运行时的资源节省。对于常驻类软件，这个交易是划算的。

三、内核迁移：从 Clash 到 Mihomo

另一个重要变化是内核换成了 Mihomo（原名 Clash Meta）。

为什么要换

Clash 原版内核的迭代逐渐放缓，而社区分支 Mihomo 保持了更活跃的开发，带来了：

对于使用者来说，最直接的体感是「能用上新协议」——当你的配置提供方开始提供这些新选项时，旧内核就成为了瓶颈。

兼容性如何

绝大多数 Clash 配置可以直接在 Mihomo 上运行，因为两者共享相同的配置格式基础。迁移过程中遇到的大多是边缘特性，日常配置基本无感。

这也是为什么版本升级时「大部分人的配置不受影响，但少数人会出问题」 —— 问题通常落在那些用了冷门特性的配置上。

四、Merge：真正的差异化功能

如果说 UI 和内核属于「跟随和改进」，那么 Merge 就属于原创性的功能设计。

它解决的是什么问题

在 Merge 出现之前，多订阅用户通常这么处理：

方案 A：手工合并（每次更新都要重来）
方案 B：写脚本自动合并（脚本本身要维护）
方案 C：用第三方合成服务（隐私 + 依赖雙重代价）

三个方案都不理想。Merge 提供了一条第四条路：让客户端在运行时自动合成，每个来源保持独立。

为什么这个功能重要

它的价值不在于「能做到」—— 手工也能做到 —— 而在于把一件重复性的事变成了一次性配置。

这个类比很贴切：就像版本控制系统不只是在「保存文件」，而是改变了你组织工作的方式。Merge 也不只是「合并配置」，它改变了你组织配置的方式。

一旦习惯了「订阅只管节点、本地文件只管规则」的分离模式，就很难回到过去那种单一大文件的做法了。

五、脚本引擎：给进阶用户的自由度

Merge 之上还有一层能力：JavaScript 脚本预处理。

它的定位

Merge 解决的是「多源合成」，脚本解决的是「内容加工」。典型场景：

• 节点命名规范化（香港 01 [1.0x] → HK-01）
• 按关键词/倍率过滤不需要的节点
• 按地区或性能自动分组

为什么说它体现了设计哲学

因为不是所有用户都需要这些功能。项目把这些高阶能力放在了「可选」的位置 —— 不用它完全不影响基本体验，需要的时候它就在那里。

这种「简单路径不复杂，复杂路径不封死」的设计，比一味堆砌功能或一味追求极简都更难把握。

六、版本升级的注意事项

结合上述演进，这里整理升级时的实用建议。

升级前的准备

务必先备份配置目录。 这不是形式主义 —— 大版本更新时确实遇到过配置兼容问题。

# 备份示例（macOS / Linux）
cp -r ~/.local/share/clash-verge-rev ~/clash-verge-backup-$(date +%Y%m%d)

Windows 上在文件资源管理器里压缩一份即可。

升级后的检查清单

• 软件能否正常启动
• 配置是否被正确加载（节点数量是否正常）
• 规则是否按预期工作（访问几个典型站点验证）
• Merge 是否仍然生效
• TUN 模式（若使用）是否正常

出问题时的回退

如果发现严重问题：

1. 卸载当前版本
2. 安装上一个稳定版本
3. 恢复备份的配置目录

这就是备份的价值所在 —— 整个过程不会超过五分钟。

关于自动更新

软件提供 update 提醒。是否自动升级取决于你的偏好：

推荐的做法是延后一两周。开源项目的大版本初期问题通常在这段时间内暴露并被修复，等一等你几乎不会有损失。

七、项目现状与展望

目前的状况：

值得关注的方向

从演进逻辑推测，后续可能的方向：

• 移动端能力补强 — 目前桌面端远强于移动端（但这是两个不同的应用）
• 配置管理进一步简化 — Merge 已经降低了门槛，可能继续下探
• 新协议的持续跟进 — 取决于 Mihomo 内核的演进

给使用者的建议

如果你正在选型，最关键的一点建议是：把「是否在活跃维护」放在功能丰富度之前考虑。

流量转发类软件一旦停止维护，它的风险敞口会随着时间线性放大。Clash for Windows 的案例已经很清楚 —— 它功能很完善，但今天已经不适合作为长期选择了。

八、从项目演进中学到的一点东西

回顾 Clash Verge Rev 的发展，有几个选择特别值得玩味：

第一，在架构上选择了「更难但更优」的路。 Tauri 在当时远不如 Electron 成熟，选择它意味着要多处理一堆系统依赖问题。但长期看，这个选择带来了持续的资源占用优势。

第二，没有试图讨好所有人。 Merge 和脚本是给进阶用户的，新手可能会觉得界面复杂。它没有为了降低上手门槛而砍掉这些能力，而是把它们放在「需要时才出现」的位置。

第三，抓住了替代窗口。 CFW 停更留下的空位，需要有人填上。它在这个时间点提供了足够好的替代方案。

这三点里，大概第三点最不可复制 —— 时机是可遇不可求的。但前两点，对任何产品都是通用的道理。

相关阅读

想了解具体的安装步骤，见《Clash Verge Rev 下载安装全攻略》；Merge 的实操配置在《Merge 混合配置实战教程》；如果想看它与其他客户端的横向对比，《主流 Clash 客户端横向评测》里有完整的六维度评分。