代理客户端常见分发方式是 GitHub Releases：APK、EXE、DMG、ZIP、tar.gz 都在同一页。页面上如果同时提供 checksums.txt、.sha256 或签名文件，就应该把它们一起下载。
校验对象怎么选
| 文件 | 是否需要校验 | 说明 |
|---|---|---|
.apk | 是 | Android 安装包，最常见 |
.exe / .msi | 是 | Windows 安装前校验 |
.dmg | 是 | macOS 下载后校验 |
.zip / .tar.gz | 是 | 解压前校验 |
checksums.txt | 来源要校验 | 必须来自同一官方 release |
不要只看文件大小。大文件在中途断开后，有些下载器会留下半截文件；文件名没变，但哈希一定不同。
各系统命令
Windows PowerShell：
Get-FileHash .\FlClash.exe -Algorithm SHA256macOS：
shasum -a 256 ./sing-box.apkLinux：
sha256sum ./mihomo-linux-amd64.tar.gz把输出的 64 位十六进制字符串，与 release 页面或 checksums.txt 里的对应文件逐字符比对。只要差一位，就视为失败。
下载镜像场景要更谨慎
GitHub 下载慢时，很多人会用反代或下载器。镜像可以提升速度，但校验必须回到官方哈希。换句话说：文件可以从镜像拉，哈希要从官方 release 页拿。需要客户端与订阅一起测试时，可选择配套订阅线路，但二进制文件仍只按官方 release 校验。
还有一个细节：不要把别人发来的哈希截图当依据。截图无法确认 release tag，也可能对应旧版本。最好复制官方页面文本，和本机命令输出放在同一个终端或记录单里比对。
检查清单
- 仓库 owner 与项目官网一致。
- release tag、文件名、系统架构匹配。
- checksum 来自同一 release 页面。
- 本机计算值与官方值完全一致。
- 团队分发时同时记录版本号和 SHA256。
校验完成后再安装，后续排查也更轻松：至少可以排除「文件坏了」这个低级但常见的问题。
客户端 release SHA256 校验的落地条件
客户端 release SHA256 校验这类工具页要把权限变化、Release 来源和系统版本写清楚。安装包只从维护者仓库、Release、应用商店或系统包源获取，生产设备只保留可追溯来源。
改配置前备份原文件，保留客户端版本、内核版本和错误日志。路由器、NAS、手机和桌面端的权限模型不同，不能把同一条命令直接搬过去。
协议兼容、规则集和订阅格式会随着客户端更新变化；正文没有覆盖的系统版本，应以维护者文档和当前 Release 说明为准。
| 项目 | 看什么 | 不宜继续的信号 |
|---|---|---|
| 权限变化 | 当前后台、日志或设置页里能直接看到的字段 | 页面提示和手头资料对不上 |
| Release 来源 | 费用、权限、地区或设备造成的实际影响 | 已经影响付款、审核、生产环境或家庭使用 |
| 系统版本 | 回退入口、旧配置、官方支持材料 | 找不到回滚方式，或责任人无法确认 |