1 换机时最容易丢的不是「客户端」，而是 Profile 与覆写
很多人以为：只要记下机场订阅链接，换电脑后重新导入，一切就能回到原样。现实里，Clash Verge Rev 里真正决定体验的，往往还包括：Profile（配置档）列表与元数据、你对某条订阅设置的更新间隔与备注、覆写（Override）里追加的 YAML 片段、以及 mixin 一类「叠在订阅之上」的本地改动。重装系统或只装客户端不拷数据目录时，这些不会跟着订阅 URL 自动长回来。
另一类常见损失是自定义规则与 Rule Provider 缓存：你在界面里勾选的策略组、为某个域名临时写的规则、或引用的本地规则文件路径，都可能依赖应用数据目录下的缓存与索引。若新机路径不同、或你只恢复了订阅而没有恢复整个工作区，就会出现「节点能测通，但分流手感完全不对」的错位感。
因此，本文把迁移定义成一条完整链路：先弄清数据放哪 → 再决定备份粒度 → 最后按顺序恢复并验收。若你更关心「更新订阅时不丢 mixin」，可并行阅读《Clash 订阅覆写入门：mixin 与规则追加》，它与本文互补：一篇讲日常增量保护，一篇讲换机整包搬迁。
Country.mmdb、订阅缓存或数据库文件，导致打包不完整或备份损坏。
2 先分清：订阅 URL、Profile、运行时配置与覆写
订阅 URL是服务商给你的令牌链接，本身不包含你在客户端里做的备注、分组与覆写。Profile是 Verge Rev 里的一份「工作配置」：可能来自远程订阅，也可能来自本地 YAML；客户端会为它保存激活状态、更新记录以及在 UI 中调整过的选项。
Mihomo 真正跑起来时，会把订阅内容与本地覆写合并成运行时配置。你在日志里看到的校验路径，往往落在应用数据目录下（例如临时校验用的 YAML）。这意味着：只备份桌面上的某一个 config.yaml，不一定等于备份了整套 Verge 状态，除非你明确只用单文件本地 Profile 且没有额外覆写。
覆写与 mixin解决的是「机场更新把本地改动冲掉」的问题；换机时，它们同样需要从旧机一并带走。否则新机上即使订阅同名，你的 prepend 规则、DNS 片段或节点重命名策略仍会丢失。具体写法与字段含义仍以覆写专题为准，本文只强调文件落点随应用数据目录走，不要只抄浏览器里的订阅链接就关机。
3 Windows：应用数据目录在哪，建议整夹备份
在 Windows 10 / 11 上，Clash Verge Rev 的应用标识为 io.github.clash-verge-rev.clash-verge-rev，日志与校验路径也多次出现在该目录下。默认位置通常是：
%APPDATA%\io.github.clash-verge-rev.clash-verge-rev\（展开后形如 C:\Users\你的用户名\AppData\Roaming\io.github.clash-verge-rev.clash-verge-rev\）。
最省心的做法是把上述文件夹整体压缩备份：其中通常包含订阅拉取后的缓存、Geo 数据库（如 Country.mmdb）、校验用的临时 YAML，以及客户端维护的 profile 与设置相关文件。子目录与文件名会随版本迭代略有变化，因此不建议新手只挑「某一个文件」拷贝，除非你清楚自己只依赖单文件 Profile。
便携版用户额外注意
若你使用便携版，部分状态仍可能写在用户级 AppData，也可能与便携目录共存。换机前请对照旧机上「实际写入路径」：以资源管理器地址栏打开 %APPDATA% 核对是否存在上述标识文件夹，并与便携根目录一并打包，避免漏夹。
与「服务模式 / TUN」相关的组件
服务模式与 TUN 驱动属于系统层安装，一般不会靠复制 AppData 就自动完整迁移到新 Windows。新机仍建议按《Windows 安装教程》重新安装服务、确认管理员权限，再导入数据。否则常见现象是：配置回来了，但虚拟网卡或系统代理开关异常。
4 macOS：Library 下的应用支持目录与时间机器
在 macOS 上，同一标识的应用数据一般位于用户资源库：
~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/
Finder 默认隐藏「资源库」。可在按住 Option 键时，通过菜单「前往 → 资源库」进入，或在终端用 open ~/Library/Application\ Support/ 快速打开父目录，再进入上述子文件夹。与 Windows 一样，建议整体备份该目录，而不是只复制某一个 YAML。
若你习惯用时间机器（Time Machine），恢复整机用户目录后，上述路径通常一并回来；若是「只重装系统、手动拷文件」，请显式检查是否遗漏 Application Support。Apple Silicon 与 Intel 之间换机，只要仍是 macOS，数据目录命名一般一致，可比 Win ↔ Mac 跨平台省心一些。
首次在新 Mac 上安装可参考《macOS 安装 Clash Verge Rev》：先让客户端能正常启动并拿到权限，再覆盖应用数据，比先覆盖再安装更不容易触发文件占用。
5 推荐迁移流程：旧机备份 → 传输 → 新机恢复 → 验收
第一步：旧机收尾
完全退出 Clash Verge Rev；如有服务模式，可在退出前暂时关闭 TUN 与系统代理，避免系统设置仍指向旧端口。然后压缩对应平台的应用数据文件夹，文件名建议带日期，例如 verge-rev-backup-20260412.zip。
第二步：安全传输
优先使用加密介质或你信任的端到端加密通道传输备份包。备份包内通常含订阅令牌与节点信息，等同于明文密码，勿上传到公共网盘不设访问控制，也不要长期留在共享下载目录。
第三步：新机安装客户端
从本站 下载页获取对应系统的安装包，完成安装与首次打开（含必要权限）。此时可先不导入订阅，直接进入下一步覆盖数据，减少重复写入。
第四步：覆盖应用数据
再次确认客户端已退出。将备份包解压，把内容合并到新机同名应用数据目录：建议先备份新机刚生成的空目录（重命名为 .bak），再把旧机内容整体拷入。若提示文件冲突，以旧机备份为准覆盖，但保留你明确知道是新版本才生成的独有文件时需谨慎——不确定则优先「整夹替换」。
第五步：启动与验收
启动后检查：Profile 列表是否完整、当前激活的配置是否正确、覆写与 mixin 是否仍生效；在规则面板抽测几条关键域名；必要时手动点一次更新订阅与 Geo 数据。若仅部分 Profile 丢失，多为备份不完整或路径拷错，而不是「订阅坏了」。
6 从 Windows 换到 macOS（或反向）时的现实预期
不要把 Windows 的 AppData 文件夹直接改名丢进 macOS 的 Application Support 里就期待 100% 可用。客户端虽同源，但路径、权限模型、服务模式与 TUN 栈不同，内部状态文件可能存在平台相关字段。更稳妥的预期是：订阅 URL、本地 YAML、覆写文本、规则片段可跨平台复用；而「整夹原封不动迁移」成功率取决于版本差，需预留手动重建 Profile 的心理准备。
实操上建议采用双层保险：一层是整夹备份（尽力恢复 UI 状态），另一层是把关键订阅链接与自定义 YAML 单独记在密码管理器或加密笔记里。这样即使整夹迁移部分失效，你仍能在新系统上快速重建分流逻辑。
跨平台后端口占用、Loopback、UWP 等问题只在 Windows 存在；macOS 则更多遇到沙箱、全磁盘访问与菜单栏权限。若你从 Mac 迁到 Windows，别忘记按 Windows 篇重装服务与处理 SmartScreen，这些步骤不会随 YAML 一起「跟过来」。
7 安全与合规：备份即高敏资产
应用数据目录里不仅有节点，还往往包含订阅原始链接与历史更新记录。任何人拿到你的备份 zip，几乎等同于拿到机场账户的访问能力。请把备份当作密钥材料：加密存储、限制设备、定期轮换订阅链接（若服务商支持），并避免在多人共用电脑上解压。
公司或学校设备上，若存在 MDM 审计或全盘备份策略，也要意识到敏感网络配置可能被纳入企业备份范围。在合规前提下，优先使用个人设备与个人账号完成代理客户端配置，能降低无意泄露风险。
8 最小化方案：只保存订阅 URL 时该怎么做
若客观条件不允许拷贝整个应用数据目录，你仍应至少保存：每条订阅的完整 URL、本地覆写与 mixin 的 YAML 文本（若在界面外另有存档）、以及自定义规则片段。新机安装客户端后，按顺序：导入订阅 → 粘贴覆写 → 核对 DNS 与规则 → 再开系统代理或 TUN。
这条路径能恢复「逻辑」，但通常恢复不了你在旧 UI 里微调过的所有细节，因此只适合应急。对重度自定义用户，仍建议回到第五节整夹迁移。
10 总结
Clash Verge Rev 的换机迁移，本质是搬迁应用数据目录 + 在新系统上重装必要的系统组件（服务 / TUN / 权限）。Windows 下记住 %APPDATA%\io.github.clash-verge-rev.clash-verge-rev\，macOS 下记住 ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/，先把整夹备份好，再谈细粒度挑选文件，能避免大部分「订阅还在、规则没了」的糟心情况。
与仅保存订阅链接相比，整夹迁移能最大限度保留 Profile 元数据、覆写与缓存，让你在新电脑上延续熟悉的分流手感；跨平台时则要有心理预案，把订阅与 YAML 文本作为第二层保险。相比在出问题后逐条手搓规则，一次性按流程备份与恢复，时间成本通常更低，也更不容易漏掉 mixin 这类隐形依赖。
若你希望在新系统上从可信渠道快速装回客户端，再按本文路径把配置接回去，相比在搜索引擎里零散拼凑路径与顺序，整体可预期性会好得多——这也是把「换机迁移」写成独立教程的意义。
