重新下载安装包之后，必须把新文件当作一份从未核对过的对象再做校验。上次对「同一版本、同一下载链接」得出的结论，不能自动套到这次落盘的文件上。校验针对的是本机这一份字节，不是版本号，也不是浏览器地址栏里的 URL。
为什么重新下载后不能沿用上次结论
每一次下载都会在磁盘上生成一份新副本。传输中断、缓存成错误页、下载管理器续传错位、保存成同名但内容不同的对象，都会让「看起来还是那个安装包」的文件与发布页上的资源不一致。上一份文件即使曾经对过摘要或对照过文件名，那次结果也只对那一份有效。
重新下载本身常常就是因为上一份已经失败：摘要对不上、体积异常、装错架构，或误下了内置 Webview2 的大体积包。若跳过对新文件的核对，等于把「再下一遍」当成已经修复，这在逻辑上不成立。同一 tag（例如某一版的 Clash.Verge_*_x64-setup.exe）在发布页上仍是确定资源，但你硬盘里的新文件是否等于那份资源，只能对这次得到的文件再判断一次。
换版本、换架构、换包装时更不能沿用旧结论。Windows 的 x64 与 ARM64、普通安装包与 *_fixed_webview2-setup.exe，macOS 的 *_aarch64.dmg 与 *_x64.dmg，Linux 的 deb/rpm 以及 amd64/arm64/armhf，都是不同文件。把 v2.5.6 的核对结果用到 v2.5.7，或把 exe 的结论用到 dmg，没有依据。
适用条件与应再核对什么
以下情况都应视为「新文件」，需要再做校验：从发布页重新保存了安装包；换了 tag 或 Stable / AutoBuild；换了系统或架构对应的资源；上一份因不完整或不匹配已删除后重下。仅在本机复制一份已经核对过、且中途未再经过网络下载的文件，才不属于本题的「重新下载」。
应再核对的内容与第一次相同，且必须钉在新文件上。第一，完整文件名是否仍与官方 Release 上为目标系统列出的资源一致，包括 Windows 不再支持 Win7、是否误选仅在企业版或无法安装 Webview2 时使用的内置 Webview2 包、macOS 芯片与 Linux 包格式。第二，若该渠道对该资源公布了摘要，用同一算法对整份新文件计算后再逐字符比对，不要复用旧摘要结果或只看文件大小。第三，部分资源旁带有同名 .sig，签名针对的是该 tag 下那一个资源；新下载的安装包要与对应的 .sig 成对看待，不能因为「上次验过签名」就跳过。发布正文若未给出该文件的哈希，则不能用「哈希已通过」作为结论，但仍须确认来源是仓库指向的 Release 页，以及文件名、架构没有下错。
具体操作与失败时下一步
操作顺序可以固定。删除或移走上一份有问题的安装包，避免同名覆盖后仍打开旧文件。只从项目发布页下载与本机对应的那一个资源，记下完整文件名。对这份新文件做文件名核对；有官方摘要则重新计算并比对；有随包 .sig 则按该资源验证，而不是沿用历史记录。核对通过后再安装；未完成核对不要开始安装。
失败时按原因处理，而不是默认「再下一遍就不用查了」。摘要或签名与参考不一致：删除新文件，回到同一官方 Release 重新获取，确认没有下成 HTML 或被中间缓存替换的对象。文件名或架构与本机不符：说明这次仍下错变体，应更换正确资源后再校验，而不是用旧版核对结果开脱。找不到官方哈希：不要拿论坛或网盘上的字符串给新文件「补验」；以发布页实际公布的信息为准，至少完成来源与文件名核对。反复失败：对照仓库安装说明，确认系统在支持范围内，并确认比较的是同一个 tag 下的同一个资源，而不是把不同版本或不同包装混在一起。
重新下载解决的是「再拿一份副本」，校验解决的是「这一份副本是不是目标资源」。两步不能互相替代；新文件出现一次，核对就要做一次。
https://github.com/clash-verge-rev/clash-verge-rev/releases https://github.com/clash-verge-rev/clash-verge-rev