先弄清改名范围：项目身份、界面名称与文件名并不总同步
如果你搜索“Mihomo Party 怎么没了”或“Clash Party 是不是另一个客户端”，先不要根据图标和文件名判断。项目当前的一手入口是 mihomo-party-org/clash-party 官方仓库，仓库标题和说明使用 Clash Party。这里的核心事实是项目入口和当前名称已经可由同一个组织仓库核对，而不是某个下载站单方面把安装包改名。
名称变更通常不会在所有位置同时完成。仓库名、程序标题、安装器文件名、系统应用列表、配置目录、自动更新元数据和旧文档可能在不同版本中保留不同称呼。因此，看见 mihomo-party 前缀不必立刻认为是假文件，看见 clash-party 也不能只凭名字确认来源。判断依据应是它们是否出现在同一官方 Release、适用的平台与架构是否明确、校验文件是否对应。
改名不等于换内核：Clash Party 是桌面客户端项目名称，Mihomo 是它所使用的核心名称。界面品牌与核心项目是两个层次，不能因为应用改名就把所有配置中的 Mihomo 字样替换掉。
也不要从改名推断许可证、数据路径或兼容性一定发生了某种变化。只有发布说明或代码明确写出的变更才能作为事实。本文聚焦于用户可验证的仓库、发布资产和迁移结果，不把名称变化包装成新功能，也不建议为了追新名称而强制升级仍然稳定的环境。
从官方仓库进入 Release，避免搜索广告和二次打包
安全的核对顺序是从组织仓库进入 Releases，而不是先搜索一个安装器文件名。确认浏览器地址的组织是 mihomo-party-org、仓库是 clash-party，再打开目标版本。记录标签、发布日期、资产名称、文件大小和可用的 SHA-256 文件。第三方教程可以帮助理解界面，但不应成为二进制文件的唯一来源。
- 打开官方仓库首页，检查组织、仓库名和项目说明。
- 从仓库内进入 Releases，选择你计划安装的明确版本。
- 根据操作系统、CPU 架构和安装形态筛选资产，不凭“最新”按钮猜测。
- 同时下载与该资产对应的 SHA-256 文件，并在本地核对。
- 保存 Release URL 与资产原名，安装后可追溯当前来源。
文件扩展名说明安装形式，不说明架构一定正确。Windows 可能有安装版或压缩版，macOS 可能按 Intel 与 Apple 芯片区分，Linux 也可能提供不同包格式与架构。设备是 ARM 还是 x64、系统允许哪种包，应该在下载前确认。不要因为文件较小、名称较短或镜像下载较快就选择无法对应到 Release 的副本。
不要把社区转载称为官方镜像：只有项目明确链接的分发位置才能沿用项目身份。网盘或下载站即使保留原文件名，也需要独立验证，且不应优先于官方发布页。
同一 Release 出现两套前缀，先按平台与校验文件配对
v2.0.2 官方发布页提供了一个很直观的过渡期样本：同一版本的 Assets 中可以同时看到以 clash-party- 和 mihomo-party- 开头的文件，并覆盖 Windows、macOS、Linux 等平台；页面还列出了相应的 .sha256 校验文件。它们位于同一个标签下，这说明不能只靠前缀把它们解释成两个互不相关的产品。
| 看到的线索 | 合理解释 | 不能据此下的结论 |
|---|---|---|
| clash-party 前缀 | 当前项目名称对应的资产 | 一定使用全新配置目录 |
| mihomo-party 前缀 | 发布过渡或兼容命名资产 | 一定是旧版或恶意文件 |
| 同一 v2.0.2 标签 | 由同一 Release 统一列出 | 任意同名外部文件也可信 |
| .sha256 文件 | 可核对下载内容完整性 | 校验通过即可忽略来源 |
选择时先匹配系统和架构，再阅读该 Release 的说明。若同平台同时提供两种前缀，不要把两套都安装来“试一试”，也不要互相覆盖后比较。选择一个能与发布说明、文件名和校验项完整对应的资产，在备份后的测试窗口内升级。若说明没有解释你所看到的差异，可以暂缓并查看仓库讨论，而不是自行编造两个前缀的功能区别。
SHA-256 用于检测本地文件是否与发布页记录一致。它可以发现下载中断或内容被替换，但校验的前提是校验值本身来自可信的官方页面。保留资产与校验文件的原名，分别计算并比对完整字符串；只看开头几位或文件大小不够。
升级前备份配置，并把“能启动”和“迁移成功”分开
改名版本可能继续读取旧数据，也可能因为平台打包、应用标识或版本跨度而采用不同位置。不要假设“同一项目所以一定无感迁移”，也不要提前手工重命名配置目录。先在现有客户端记录版本、当前配置、订阅名称、代理模式、覆写设置和核心状态，再使用应用提供的导出或备份功能。若复制数据目录，应先完全退出程序并保护其中的订阅 Token。
安装包、应用程序与用户数据需要分别备份。保存旧安装器或便携目录，可以恢复程序；导出的配置和完整数据副本用于恢复个人状态；二者不能互相替代。若设备空间允许，先把新版本放在可回退的测试环境中。不要在确认数据加载之前卸载旧版并选择删除用户数据。
- 记录旧版名称、完整版本和下载来源。
- 导出配置，并在程序退出后复制实际数据目录。
- 保存订阅名称、当前策略组和关键覆写的脱敏截图。
- 验证备份文件存在、非空，并放在应用目录之外。
- 只安装一套与系统匹配的新资产，首次启动先不更新订阅。
- 对照旧记录，确认无误后再恢复自动更新与日常使用。
如果新版本出现空配置，不要立即覆盖它的目录。先退出，确认新旧应用实际读取的路径，再决定使用内置导入还是复制经过验证的备份。混合两个版本生成的索引文件和单个 YAML，可能造成重复、丢失覆写或引用不存在文件。恢复动作一次只用一个完整来源。
升级后验证名称、版本、核心与代理功能，再决定清理旧文件
首次启动后先查看 About 或版本页面，确认应用版本与 Release 标签一致，并记录界面当前显示的是 Clash Party 还是过渡名称。接着查看核心版本、配置列表、代理组和日志。名称显示正确不代表功能完成，旧名称残留也不必然表示安装错误；关键是程序身份可追溯、数据完整、核心能运行。
- 程序：版本号、平台架构和发布资产相符。
- 数据：订阅条目、覆写、模式与重要偏好完整。
- 核心：能启动并持续运行，没有崩溃重启循环。
- 代理：固定节点和 rule 模式下能产生一条可解释的连接。
- 回退：旧程序与配置备份仍可访问，没有提前删除。
自动更新若仍显示 Mihomo Party 名称，应先看它请求的仓库与版本，不要只凭文字判断被劫持。相反，即使弹窗写 Clash Party，也应核对目标 URL。品牌文字是视觉线索，组织、仓库、标签、资产和哈希组成的链路才是来源证据。
清理条件：至少完成一次关闭重开、一次配置加载和一次实际连接，再保留备份观察一段时间。确认无需回退后，才删除重复安装器或废弃测试目录。
后续写教程或给同事发送链接时，可以表述为“Mihomo Party 项目现使用 Clash Party 名称”，并直接链接官方仓库。不要把过渡期的两个安装文件描述成两个独立官方客户端，也不要承诺未来版本永远保留旧前缀；资产策略应以具体 Release 为准。
官方来源与版本边界
版本号、文件名和界面文字可能随项目更新而变化，操作前请以链接中的项目文档为准。