Clash 电脑端要保存“有来源”的旧版本安装资料，核心不是多复制一份安装包，而是让日后任何人都能根据公开记录核对：这份文件对应哪一个官方标签、面向哪一种系统与架构、以及当时发布说明写了哪些限制。Clash Verge Rev 在项目说明中要求到发布页面下载对应安装包，并写明支持 Windows、Linux 与 macOS 11+；发布页按标签提供带版本号的资源。只有把标签、文件名和说明放在一起，旧包才具备可追溯来源，而不是变成来路不明的同名程序。
适用条件与必须一起留下的信息
本做法适用于已经使用 Clash Verge Rev 电脑端、需要保留可回退安装包或做版本对照的场景。官方把发行渠道分成正式版（Stable，说明为高可靠性、适合日常使用）和滚动更新的 AutoBuild（适合测试反馈，可能存在缺陷）；Alpha 被标明废弃。保存旧版本时，应优先归档正式版标签，并写清标签名。发布记录中可见的标签包括 v2.5.7、v2.5.6、v2.5.5 等，它们各自带有独立的资源列表与说明正文。
需要归档的对象至少包括：安装包本身、同一标签下的签名文件（资源名中带 .sig 的文件）、以及该标签的说明摘要。Windows 提供 x64 与 ARM64 的常规安装包，另有体积较大的内置 WebView2 包，说明仅在企业版系统或无法安装 WebView2 时使用；macOS 区分 Apple 芯片与 Intel 芯片；Linux 提供 DEB 与 RPM，并分别列出 64 位、ARM64、ARMv7。Windows 发布说明写明不再支持 Win7。判断一份旧包“能不能用”，要看该标签说明中的系统范围，而不是文件能否被复制到磁盘。
按官方发布页保存的步骤
第一步，只从官方发布页获取文件：https://github.com/clash-verge-rev/clash-verge-rev/releases 。来源判断依据是标签名、资源文件名与该页分类是否一致，而不是安装包能否运行。
第二步，把 tag 名称与资源文件名原样记录。文件名中已含版本号与架构信息，保存时不要改掉这些字段。若需要对照问题修复范围，把该标签说明一并存放。例如较新标签分别写过 Windows 服务与 TUN、macOS 系统代理读取、服务停止时内核来不及正常退出等条目，这些文字是判断“旧包解决的是哪一类问题”的依据。
第三步，按本机系统挑选资源：Windows 对号入座架构；macOS 区分芯片；Linux 按官方写法用发行版对应的包格式处理路径中的文件。同一目录同时放下对应 .sig，避免日后只剩安装包、无法说明它属于哪一次发布。
第四步，写一份纯文本对照表，至少包含标签、完整文件名、目标系统、架构、是否为内置 WebView2 包、保存日期。订阅相关备注只保留 token= 这类参数片段，不写完整网址，也不编造域名。
对不上来源时的下一步
若目录里只有安装包、没有标签与说明，来源不完整。应回到同一发布页，用文件名中的版本号重新定位标签，补齐说明与签名文件。若文件名与任何公开标签都对不上，不应把它当作该仓库的旧版本安装资料。
若保存的是 AutoBuild 或已废弃的 Alpha，必须在对照表中标明渠道，避免与正式版混放。官方已说明 AutoBuild 可能存在缺陷；需要回到日常使用渠道时，应改选正式版标签下的包。架构或包类型与系统不符时，应重新按发布页分类下载，而不是改后缀或跨架构安装。Windows 上还要区分常规包与内置 WebView2 包，后者有明确的适用条件。项目说明与发布页见 https://github.com/clash-verge-rev/clash-verge-rev 与 https://github.com/clash-verge-rev/clash-verge-rev/releases 。