-
Notifications
You must be signed in to change notification settings - Fork 0
Windows vs macOS Benchmark
欢迎阅读 Clash Verge Rev Windows 与 macOS 性能测试指南。
关于这个话题，网上已经有很多讨论。
有人认为 Windows 版本速度更快，也有人觉得 macOS 使用起来更加流畅；有人喜欢 Windows 丰富的兼容性，也有人认为 Apple Silicon 的续航和稳定性更好。
如果只看评论区，很容易得到完全相反的结论。
事实上，大多数争论都忽略了一个关键问题：不同平台的表现，并不能简单地用"快"或"慢"来概括。
同样一份配置文件、同样一个节点，在不同硬件、不同系统版本，甚至不同网络环境下，都可能得到完全不同的测试结果。
因此，本篇文章不会直接告诉你哪一个平台更优秀，而是尽可能以统一的测试方法，从启动速度、资源占用、规则加载、订阅更新、TUN 模式、节点切换等多个维度进行分析，让你能够根据自己的使用场景做出选择。
如果你刚开始接触 Clash Verge Rev，建议先完成基础配置，再阅读本篇内容。
推荐阅读：
- Clash-Verge-Rev-Installation-Guide
- System-Requirements
- Enable-TUN-Mode
- Rule-Based-Proxy-Configuration
很多用户更换电脑后，第一件事就是安装 Clash Verge Rev。
安装完成后，经常会产生一些疑问：
- 为什么 Windows 上启动速度感觉更快？
- 为什么 macOS 的动画更流畅？
- Apple Silicon 是否真的更省电？
- Windows 开启 TUN 后为什么 CPU 占用会变化？
- 为什么同一个节点，两台电脑测速结果不同？
这些问题没有统一答案。
因为代理客户端并不是一个独立运行的软件，它会受到很多外部因素影响。
例如：
- CPU 架构
- 内存容量
- 磁盘类型
- 操作系统调度
- 网络驱动
- DNS 配置
- 节点质量
- 配置文件大小
- Rule 数量
- TUN 是否开启
因此，如果忽略这些变量，任何"平台更快"的结论都缺乏参考价值。
很多人理解 Benchmark，就是打开软件，看谁启动更快。
实际上，对于代理客户端来说，启动速度只是其中很小的一部分。
真正影响长期使用体验的，还包括：
- 软件首次启动时间
- 配置文件加载速度
- 节点列表渲染速度
- Rule 解析效率
- Mihomo 内核启动时间
- 节点切换响应速度
- DNS 查询表现
- 日志刷新流畅度
- 长时间运行后的资源占用
- 系统休眠恢复后的稳定性
这些项目共同决定了日常使用体验。
因此，后续章节会围绕这些维度逐一展开，而不是只关注某一个测试数据。
这是社区里最常见的问题。
有人说：
Windows 打开软件只需要一秒。
也有人说：
我的 macOS 更快。
实际上，两个人都可能是对的。
因为他们使用的环境完全不同。
例如：
第一位用户：
- Windows 11
- AMD Ryzen 7
- NVMe SSD
- 32GB 内存
- 200 条规则
第二位用户：
- macOS Sonoma
- Apple M3
- 16GB 内存
- 8000 条规则
- 多个 Rule Provider
即使使用同一个版本的 Clash Verge Rev，也不具备直接对比的意义。
Benchmark 的核心，不是比较谁更快，而是在尽可能统一条件下观察不同平台的表现。
为了让测试结果更具有参考意义，本文采用以下原则：
第一，坚持相同的软件版本。
Windows 与 macOS 使用相同版本的 Clash Verge Rev，避免因版本更新导致功能差异。
第二，保持一致的配置文件。
包括：
- 相同节点数量
- 相同 Rule 配置
- 相同 Rule Provider
- 相同 DNS 设置
- 相同代理模式
避免因为配置复杂度不同而影响结果。
第三，保持相近的网络环境。
例如：
- 同一网络运营商
- 同一路由器
- 相同出口线路
这样可以减少网络波动带来的误差。
第四，重复测试。
单次测试很容易受到后台任务、系统更新或缓存影响。
因此，每个测试项目都会进行多次观察，更关注整体趋势，而不是某一次的峰值。
很多用户认为，只要硬件性能高，代理客户端一定更快。
实际上，并非如此。
下面这些因素，都会影响最终体验。
目前常见的平台包括：
- Intel x64
- AMD x64
- Apple Silicon
不同架构在资源调度和能耗管理方面存在差异，因此表现也会有所不同。
Windows 10、Windows 11，以及不同版本的 macOS，在网络栈、驱动和后台管理机制上都有变化。
因此，同一台电脑升级系统后，代理软件的表现也可能发生改变。
只有几十条规则的配置，与包含数万条规则、多个 Rule Provider 的配置，在启动和加载速度上会有明显区别。
对于大型配置文件来说，规则组织方式往往比规则数量更加重要。
很多订阅包含数百甚至上千个节点。
节点越多：
- 首次解析时间可能越长。
- 节点列表加载时间可能增加。
- 延迟测试耗时也可能更长。
因此，节点数量也是 Benchmark 中需要控制的重要变量。
TUN 模式会接管更多网络流量，因此：
- CPU 使用率可能发生变化。
- 网络驱动参与更多工作。
- 不同平台的表现也可能不同。
因此，后续测试会分别观察开启与关闭 TUN 时的情况，而不是只测试一种模式。
很多人看到 Benchmark，会想到各种跑分软件。
但对于 Clash Verge Rev 而言，更重要的是日常体验。
例如：
你每天都会进行这些操作：
- 更新订阅。
- 切换节点。
- 浏览网页。
- 使用 GitHub。
- 打开 ChatGPT。
- 下载项目代码。
- 查看实时日志。
- 长时间保持后台运行。
这些真实场景，比单纯的启动速度更有参考价值。
因此，本文更关注长期使用中的稳定性、响应速度和资源管理，而不是某一个数字的高低。
在阅读后续内容之前，需要先建立一个正确的认知。
如果某个平台在某一项测试中表现更好，并不意味着它在所有场景下都占优势。
例如：
启动速度领先，并不代表长时间运行后资源占用更低。
内存占用较少，也不意味着节点切换一定更快。
因此，每个测试项目都应该结合自己的实际需求来看，而不是简单追求"第一名"。
Benchmark 的价值，不是替用户做决定，而是帮助用户理解不同平台在不同场景下可能呈现出的特点。
如果你属于以下情况，本篇内容会比较有参考价值：
- 正在选择 Windows 或 macOS 作为日常开发设备。
- 同时拥有两台不同平台的电脑，希望比较使用体验。
- 计划升级到 Apple Silicon，希望了解实际表现。
- 想优化 Clash Verge Rev 的启动速度或资源占用。
- 希望构建一套长期稳定、易维护的代理环境。
即使你目前只使用其中一个平台，也可以通过了解另一平台的特点，更容易判断哪些问题来自软件本身，哪些问题与系统环境有关。
上一篇主要介绍了为什么不能简单地说 "Windows 一定比 macOS 快"，以及本系列 Benchmark 的测试思路。
接下来，我们正式进入实际体验阶段。
不过，在开始之前，需要先说明一点。
很多用户第一次安装 Clash Verge Rev 后，最关心的往往是软件启动速度。
例如：
- 软件多久可以打开？
- 节点什么时候全部加载完成？
- 什么时候可以开始代理？
- 为什么有时候第一次启动比较慢？
这些都是非常正常的问题。
但是，启动速度只是整个使用体验中的一个环节。
对于一款每天都会运行几个小时甚至全天后台运行的代理客户端来说，更值得关注的是：
- 启动是否稳定；
- 长时间运行是否流畅；
- 是否容易出现卡顿；
- 系统资源是否持续增长；
- 节点切换是否及时响应。
因此，本章不会只关注"几秒钟启动完成"这样单一的数据，而是结合实际使用体验进行分析。
很多人认为，双击 Clash Verge Rev 图标之后，软件就已经启动完成。
实际上，从点击图标到真正能够开始代理，中间还会经历多个步骤。
通常包括：
- 初始化程序界面。
- 加载用户配置。
- 启动 Mihomo 内核。
- 读取规则文件。
- 加载代理组。
- 初始化 DNS。
- 初始化日志模块。
- 恢复上一次使用状态。
- 检查系统代理。
- 根据设置启动 TUN（如果启用）。
这些步骤共同组成了软件启动过程。
因此，启动时间不仅受到电脑性能影响，也会受到配置复杂程度影响。
不少用户都会发现：
安装完成后的第一次启动，明显比之后几次慢一些。
这是比较正常的现象。
第一次启动时，软件通常需要完成更多初始化工作，例如：
- 创建配置目录。
- 初始化缓存。
- 建立日志文件。
- 检查运行环境。
- 生成部分本地数据。
这些工作完成后，后续再次启动通常会更加顺畅。
因此，不建议仅根据第一次启动速度判断整体性能。
在 Windows 平台，启动速度通常受到几个因素影响：
首先是磁盘性能。
如果系统安装在 NVMe SSD 上，配置文件和缓存读取速度通常更快。
其次是安全软件。
部分安全软件会在程序启动时进行扫描。
如果扫描时间较长，用户会感觉软件启动变慢。
另外，Windows 后台同时运行的软件数量，也会影响启动响应。
例如：
- 云同步工具；
- 下载软件；
- 虚拟机；
- 浏览器大量标签页；
- 开发工具。
后台负载越高，系统资源竞争越明显。
因此，同一台电脑，不同时间启动软件，体验也可能略有不同。
macOS 在资源调度方面，与 Windows 有一些不同。
特别是在 Apple Silicon 平台，系统对于后台应用的管理更加积极。
很多用户会感觉：
软件启动动画更加自然。
窗口响应更加连贯。
这并不一定意味着真正的初始化速度更快，而是系统在界面渲染上的体验更加平滑。
另外，macOS 在首次运行新程序时，通常会请求：
- 网络权限；
- 本地网络权限；
- 通知权限；
- 辅助功能权限（部分场景）。
如果这些权限尚未完成授权，第一次启动可能会稍慢一些。
完成授权后，后续启动通常会恢复正常。
这是很多用户容易忽略的一点。
如果配置文件中：
- 节点数量很多；
- Rule Provider 较多；
- 自定义规则较复杂；
那么启动阶段需要完成更多解析工作。
例如：
只有几十条规则的配置文件。
与包含几万条规则、多个规则集的配置文件。
启动时间通常不会完全相同。
不过，这并不意味着规则越多就一定越慢。
真正影响效率的，往往是：
- 规则组织方式；
- 是否存在重复规则；
- 是否加载了大量暂时不会使用的规则集。
因此，合理规划规则，比盲目增加规则更重要。
理论上，节点数量增加，会增加一定的读取时间。
但是在日常使用中，影响通常没有想象中那么明显。
真正需要关注的是：
节点是否长期维护。
很多订阅包含：
- 已失效节点；
- 重复节点；
- 长期无法连接的节点。
这些节点虽然不会直接影响启动，但会增加测速、节点切换以及维护成本。
建议定期整理节点，只保留真正会使用的部分。
这样不仅管理更加方便，也能减少后续操作中的等待时间。
不少用户打开任务管理器后，会第一时间关注：
"为什么 Clash Verge Rev 占用了这么多内存？"
实际上，仅仅看到一个数字，并不能说明问题。
更重要的是观察：
- 软件启动后的内存变化；
- 长时间运行后是否持续增长；
- 节点切换后是否能够稳定；
- 更新订阅后是否恢复正常。
如果内存保持相对稳定，即使数字略高，也并不意味着存在问题。
反之，如果持续增长且无法释放，就值得进一步排查配置或插件。
CPU 使用率也是很多 Benchmark 喜欢展示的数据。
不过，需要结合实际场景来看。
例如：
刚启动软件时。
Mihomo 正在：
- 加载配置；
- 初始化规则；
- 建立连接。
CPU 使用率短时间上升，是正常现象。
同样，在以下操作中：
- 更新订阅；
- 延迟测速；
- 批量切换节点；
- 更新 Rule Provider；
CPU 使用率也可能暂时提高。
真正值得关注的是：
在软件空闲状态下，CPU 是否能够恢复到较低水平。
如果长期保持较高占用，就需要进一步检查：
- 是否存在异常日志；
- 是否存在循环更新；
- 是否加载了异常规则。
会有一定影响，但需要正确理解。
开启 TUN 后，更多网络流量会经过 Mihomo。
因此：
- CPU 工作量可能增加；
- 网络驱动参与更多处理；
- 日志数量可能更多。
不过，在现代硬件上，这部分开销通常处于可接受范围。
对于日常浏览网页、办公和开发来说，通常不会产生明显影响。
如果开启 TUN 后资源占用突然异常增加，更应该检查：
- 网络环境；
- 配置文件；
- 是否存在大量异常连接。
而不是简单认为 TUN 本身存在问题。
这是很多用户都会遇到的情况。
例如：
CPU 很低。
内存也正常。
但是：
节点切换慢。
界面刷新延迟。
日志滚动不流畅。
这类问题并不一定来自硬件。
很多时候可能与：
- 节点响应速度；
- DNS 查询；
- 网络波动；
- 配置复杂度；
- 系统后台任务；
有关。
因此，Benchmark 不应该只看资源占用数字，更要结合实际操作体验。
对于代理客户端来说，真正影响体验的，往往是一些容易被忽略的小细节。
例如：
打开电脑后，软件是否能够快速恢复工作状态。
切换 Wi-Fi 后，代理是否能够自动恢复。
从睡眠模式唤醒后，是否需要重新连接节点。
更新订阅时，界面是否仍然保持流畅。
这些细节，比单纯快零点几秒的启动速度更能影响每天的使用体验。
长期使用过程中，稳定性通常比极限性能更加重要。
无论是 Windows 还是 macOS，软件启动速度都会受到：
- 系统环境；
- 配置复杂度；
- 节点数量；
- 规则数量；
- 网络状态；
- 后台负载；
等多个因素共同影响。
真正优秀的使用体验，不只是启动快，而是在长时间运行过程中保持稳定、响应及时、资源占用合理。
对于 Clash Verge Rev 来说，一个经过合理维护的配置，往往比单纯更换硬件、更换系统，更能够提升日常体验。
对于很多用户来说，真正影响每天使用体验的，并不是软件第一次启动用了多少秒。
当 Clash Verge Rev 成为日常网络工具之后，更多时间其实是在后台运行。
每天都会重复这些操作：
- 更新订阅。
- 切换节点。
- 查看日志。
- 修改配置。
- 更新 Rule Provider。
- 浏览网页。
- 使用开发工具。
- 长时间保持后台运行。
这些操作虽然看起来不起眼，却决定了软件是否真正"好用"。
这一部分，我们就从这些最常见的使用场景开始分析。
不少用户都会发现：
昨天更新订阅几乎瞬间完成。
今天却需要等待几十秒。
很多人第一反应就是：
是不是 Clash Verge Rev 出问题了？
实际上，大多数情况下，并不是客户端本身的问题。
一次订阅更新通常会经历几个步骤：
第一步：
连接订阅服务器。
第二步：
下载配置文件。
第三步：
解析 YAML。
第四步：
生成代理组。
第五步：
重新加载规则。
第六步：
刷新界面。
只要其中任何一个环节变慢，用户都会感觉整个更新速度下降。
因此，订阅更新速度不仅受到软件影响，更与网络环境、订阅服务器质量以及配置复杂程度密切相关。
有些订阅只有几十个节点。
也有一些订阅包含：
- 数百个节点；
- 多个代理组；
- 多个 Rule Provider；
- 大量规则集。
配置文件越大，需要解析的信息也越多。
不过，这并不意味着大型配置一定体验不好。
如果配置结构清晰、规则组织合理，即使节点较多，日常使用仍然可以保持较好的响应速度。
真正需要避免的是：
长期保留已经失效的节点、重复代理组以及不再使用的规则。
定期整理配置，比不断增加内容更加重要。
越来越多的配置开始使用 Rule Provider。
它最大的优势是：
规则可以独立维护。
更新时，只需要更新规则集，而不需要重新修改整个配置文件。
但是，如果一次加载大量 Rule Provider，也会增加初始化工作。
例如：
软件需要：
- 检查规则是否存在更新；
- 下载最新规则；
- 校验文件；
- 重新建立索引。
因此，建议只保留真正需要的规则集。
对于普通用户来说，保持配置简洁，往往比追求"什么规则都加载"更容易维护。
很多网络问题，看起来像节点故障。
实际上却与 DNS 有关。
例如：
网页一直转圈。
应用提示无法连接。
部分网站偶尔可以打开。
这些现象，有时并不是代理协议的问题，而是在域名解析阶段已经出现异常。
DNS 配置是否合理，会直接影响：
- 网站首次打开速度；
- 节点连接效率；
- Rule 是否能够正确匹配；
- Fake-IP 是否正常工作。
因此，Benchmark 中不能忽略 DNS。
即使两个平台使用相同节点，如果 DNS 配置不同，实际体验也可能完全不同。
详细内容可参考：
很多评测都会比较：
"节点切换用了几秒。"
实际上，更值得关注的是：
切换之后，网络是否能够快速恢复。
例如：
浏览器是否需要刷新。
终端是否重新建立连接。
视频是否继续播放。
开发工具是否能够保持在线。
这些体验往往比数字本身更重要。
一个优秀的代理客户端，不只是切换动作快，更应该尽量减少切换过程中对当前工作的影响。
很多用户平时几乎不会打开 Logs 页面。
直到出现问题时，才发现日志的重要性。
实际上，日志不仅用于排查故障。
也是观察客户端运行状态的重要窗口。
例如：
更新订阅时。
切换节点时。
DNS 查询时。
建立连接时。
都会产生对应日志。
如果日志能够及时刷新，说明整个网络处理流程比较顺畅。
如果日志明显延迟，或者出现大量重复信息，就值得进一步检查配置。
对于开发者或者重度用户来说，Clash Verge Rev 往往会连续运行数天甚至更长时间。
相比启动速度，更值得关注的是：
长时间运行之后：
是否仍然保持稳定。
例如：
- 内存是否持续增长；
- 日志是否正常滚动；
- 网络是否偶尔中断；
- TUN 是否持续工作；
- DNS 是否保持稳定；
- 系统休眠恢复之后是否能够重新建立连接。
这些问题虽然不容易通过一次测试发现，却更接近真实使用场景。
两个平台都能够稳定运行 Clash Verge Rev。
不过，它们对后台程序的管理方式并不完全相同。
Windows 更强调程序之间的兼容性。
大量开发工具、浏览器以及虚拟化软件可以同时运行。
macOS 则更加注重资源调度和功耗管理。
尤其是在 Apple Silicon 平台，系统会更加积极地管理后台任务。
对于普通用户而言，这种差异更多体现在整体使用体验，而不是某一个性能指标。
因此，不建议仅根据单项测试结果判断哪个平台更适合自己。
如果你的日常工作涉及：
- GitHub；
- Docker；
- Kubernetes；
- VS Code；
- JetBrains IDE；
- Cursor；
- OpenAI API；
那么建议关注以下几个方面：
是否能够快速切换节点。
Rule 是否容易维护。
日志是否方便定位问题。
订阅更新是否稳定。
TUN 是否与开发环境兼容。
这些细节，会比单纯的启动速度更直接影响工作效率。
一篇有价值的 Benchmark，并不是为了证明某个平台一定领先。
真正重要的是：
帮助用户了解：
哪些因素可以优化。
哪些问题来自网络。
哪些问题来自配置。
哪些问题来自系统环境。
理解这些之后，即使更换电脑、更换系统，也能够更快找到适合自己的配置方式。
相比一次性的启动测试，订阅更新、规则加载、DNS 查询、日志响应以及长期后台运行，更能够反映 Clash Verge Rev 在日常使用中的整体体验。
无论选择 Windows 还是 macOS，一个维护良好的配置、合理的规则组织方式以及稳定的网络环境，通常都会比单纯更换平台带来更明显的体验提升。
经过前面的内容，我们已经分别了解了：
- 软件启动流程；
- 资源占用特点；
- 订阅更新机制；
- Rule 加载方式；
- DNS 与日志模块；
- 长时间后台运行体验。
看到这里，相信很多读者仍然会有一个问题：
Windows 和 macOS，到底应该选择哪一个？
事实上，并不存在一个适合所有人的标准答案。
真正影响使用体验的，往往不是操作系统，而是你的工作内容、网络环境以及配置方式。
因此，这一章不会简单地下结论，而是结合不同使用场景，帮助你找到更适合自己的选择。
对于主要用于：
- 浏览网页；
- 在线学习；
- 视频播放；
- 日常办公；
- 社交聊天；
无论 Windows 还是 macOS，都能够提供比较稳定的使用体验。
真正需要关注的是：
- 是否完成正确安装；
- 是否开启 Rule 模式；
- 是否使用稳定的订阅；
- 是否正确配置 DNS；
- 是否定期更新 Mihomo 内核。
如果这些基础配置都已经完成，那么两个平台在日常使用中的差异通常不会特别明显。
建议优先选择自己已经熟悉的操作系统，而不是为了代理软件单独更换平台。
开发环境通常比普通办公更加复杂。
例如：
- GitHub
- Docker
- Kubernetes
- VS Code
- JetBrains IDE
- Cursor
- SSH
- Git
- API 调试工具
这些工具几乎每天都会访问大量网络资源。
相比启动速度，更值得关注的是：
- 节点切换是否稳定；
- Rule 是否容易维护；
- TUN 是否兼容开发环境；
- DNS 是否解析稳定；
- 日志是否方便排查问题。
建议：
建立一份长期维护的配置文件，而不是频繁更换节点或者不断修改规则。
如果开发环境长期保持稳定，工作效率通常会比追求极限性能更高。
Apple Silicon（M 系列芯片）已经成为很多开发者和设计人员的主要工作平台。
对于 Clash Verge Rev 来说，更值得关注的是：
- 使用对应平台的安装包；
- 保持系统版本更新；
- 定期更新 Mihomo 内核；
- 不要混用不同来源的配置文件。
很多用户遇到的问题，并不是 Apple Silicon 本身，而是迁移旧配置之后产生的兼容性问题。
如果从一开始就建立一套规范的配置，后续维护会轻松很多。
Windows 拥有更丰富的硬件生态。
不同品牌、不同型号、不同驱动都会影响实际体验。
建议重点关注以下几个方面：
第一：
保持系统网络驱动正常。
第二：
确认系统时间同步。
第三：
避免多个代理软件同时运行。
第四：
及时更新 Clash Verge Rev 与 Mihomo。
第五：
定期整理配置文件。
很多网络问题，其实来自多个代理软件共同修改系统代理，而不是 Clash Verge Rev 本身。
这是很多用户都会忽略的一件事。
随着使用时间增加，配置文件往往越来越复杂。
例如：
增加新的节点。
增加新的规则。
增加新的 Rule Provider。
增加新的 DNS。
如果没有定期整理：
几年之后，配置文件可能已经很难维护。
建议建立一个固定的维护习惯：
- 删除已经失效的节点；
- 清理重复规则；
- 保留真正需要的代理组；
- 定期检查 Rule Provider；
- 更新 Mihomo 内核；
- 备份重要配置。
相比不断寻找新的配置模板，一个长期维护的配置更可靠。
很多 Benchmark 喜欢比较：
- 启动速度；
- CPU 使用率；
- 内存占用。
这些数据当然有参考价值。
但是对于代理客户端来说，还有一些更加重要的体验：
例如：
电脑睡眠恢复之后：
是否能够立即恢复网络。
切换 Wi-Fi 后：
是否自动重新建立连接。
订阅更新：
是否顺利完成。
规则更新：
是否正常加载。
DNS：
是否保持稳定。
这些真实场景，比一次性的性能测试更接近日常使用。
社区里有一种比较常见的现象。
看到新的配置：
立即替换。
看到新的规则：
立即导入。
看到新的教程：
再次修改。
几个月之后：
已经不知道哪些配置真正生效。
建议：
一旦建立了一套稳定配置，就不要频繁调整。
每次修改：
只调整一个项目。
完成测试后：
再继续下一步。
这样出现问题时，更容易定位原因。
实际上：
规则数量并不是衡量配置质量的标准。
结构清晰、维护方便，往往比数量更多更加重要。
节点数量增加，并不会自动提升体验。
相反：
过多无效节点会增加管理成本。
建议保留真正稳定、长期可用的节点。
每个人的：
- 网络环境；
- 硬件配置；
- 系统版本；
- 使用方式；
都不相同。
因此：
Benchmark 更适合作为参考，而不是唯一标准。
实际上：
很多问题来自：
- DNS；
- 网络运营商；
- 路由器；
- 系统配置；
- 第三方安全软件。
排查问题时，应结合日志和网络环境进行分析，而不是直接认为客户端存在故障。
如果希望获得稳定、长期的使用体验，可以参考下面的建议：
- 使用最新稳定版本的 Clash Verge Rev。
- 定期更新 Mihomo 内核和规则集。
- 根据自己的网络环境配置 DNS，而不是直接照搬他人的配置。
- 保持 Rule 结构清晰，避免重复规则。
- 开启 TUN 前，确认系统权限和网络驱动正常。
- 家庭或办公环境建议开启 Bypass LAN，保证局域网设备正常通信。
- 每次修改配置后进行简单测试，例如网页访问、Git 操作、订阅更新以及局域网访问。
- 重要配置建议定期备份，避免误修改导致无法恢复。
长期来看，一套稳定、易维护的配置，比不断追求新的技巧更有价值。
Windows 与 macOS 都能够稳定运行 Clash Verge Rev。
真正影响使用体验的，不只是操作系统本身，还包括：
- 网络环境；
- 配置文件质量；
- Mihomo 内核版本；
- Rule 组织方式；
- DNS 设置；
- TUN 配置；
- 长期维护习惯。
对于大多数用户而言，选择自己熟悉的平台，并持续优化配置，通常比频繁切换系统更能提升实际体验。
Benchmark 的意义，不是告诉大家哪个平台"获胜"，而是帮助用户了解不同平台在不同场景下的特点，从而建立更加稳定、高效且适合自己的代理环境。
如果你希望进一步优化 Clash Verge Rev，建议继续阅读以下 Wiki：
- Clash-Verge-Rev-Installation-Guide
- System-Requirements
- Enable-TUN-Mode
- DNS-Leak-Protection-Setup
- Rule-Based-Proxy-Configuration
- Custom-Rules-Tutorial
- Fake-IP-vs-Redir-Host
- Bypass-LAN
- How-to-Update-Clash-Verge-Rev
- Clash-Verge-Rev-FAQ
这些内容覆盖了安装、配置、规则管理、DNS、TUN、性能优化以及故障排查等多个方面。建议按照 Wiki 的顺序阅读并结合自己的使用环境实践，逐步建立一套适合长期维护的 Clash Verge Rev 配置体系，而不是依赖单一配置模板或一次性的性能测试结果。