官方源和镜像源差在哪？
| 项目 | 官方 Release | 镜像源 |
|---|---|---|
| 版本来源 | 仓库 tag | 同步副本 |
| 可追溯性 | commit、tag、asset | 取决于镜像说明 |
| 速度 | 不一定快 | 通常更快 |
| 风险点 | 误进假仓库 | 文件被替换或滞后 |
下载前看哪 4 项？
第一看仓库 owner 是否和项目官网或文档一致。第二看 release tag 是否存在于官方页面。第三看 asset 文件名和系统架构。第四看大小和哈希。
如果镜像页面只给按钮，不给来源 tag 和同步时间，就不要把它当成可信版本说明。
SHA256 怎么核对？
macOS 和 Linux 用 shasum -a 256 文件名，Windows PowerShell 用 Get-FileHash -Algorithm SHA256。
校验值要来自官方仓库、签名文件或项目维护者说明，而不是下载同一镜像页面旁边的随机文本。
假仓库最常见的伪装是什么？
项目名相似、头像相似、release 数量很少、README 只放下载按钮。还会把旧项目 fork 后改名，制造像官方源的外观。
看 owner 历史、star 变化、issue 活跃度和官网链接，比看页面美观更可靠。
怎么确认这次下载可以使用？
官方仓库、tag、asset、哈希四项一致后，再安装。安装包首次运行前，保留下载记录和校验结果，方便回滚到上一版。
主编补充：执行前后怎么留痕
GitHub Release 官方源和镜像源怎么辨别这类问题，读完「官方源和镜像源差在哪？」之后，先写下当前状态：谁在操作、用的哪个账号或设备、最近改过什么。再对照「下载前看哪 4 项？」每次只改一个变量，成功和失败都截图或保存日志。客户端配置要先保存原文件和日志，再改订阅、DNS 或规则。这样下次同类问题出现时，团队不用重新猜原因。
交付前再做一次复核
GitHub Release 官方源和镜像源怎么辨别处理完以后，不要只看页面是否恢复。先把这次改过的客户端配置、DNS、路由规则和日志列成一行记录，写清楚原值、新值、操作人和时间点。再回到「官方源和镜像源差在哪？」和「下载前看哪 4 项？」两处，对照正文里的判断条件复测一次。
如果复测结果和预期不同，先回滚最近一次修改，再看日志或后台提示是否变化。这样做会多花几分钟，但能避免下次同类问题出现时，只剩一句「之前好像改过」。团队协作时，这条记录也能直接变成客服回复、工单备注或内部 SOP 的证据。
相关阅读
FAQ
镜像源下载的文件一定不安全吗？
不能这样判断。镜像可以作为传输通道，但版本信息和校验值要回到官方仓库确认。
只看文件名一样够不够？
不够。文件名容易复制，至少还要核对 tag、文件大小和 SHA256。重要客户端还要看签名或校验文件。
Release 页面没有 SHA256 怎么办？
优先找项目说明、校验文件或签名文件。都没有时，至少从官方 GitHub 页面下载一次作为基准。