GitHub 下载文件 SHA256 校验完整教程：Windows / macOS / Linux 三步验证文件完整性（2026）
从 GitHub Release 下载的 .exe/.dmg/.apk 不一定和发布者上传的完全一致。SHA256 校验能把下载的文件算出一个 64 位指纹，和发布者公布的指纹比对，一致才说明文件完好。这篇给出 certutil、shasum、sha256sum 三种命令、SHA256SUMS 文件读法和校验失败时的排查顺序。
操作步骤速查
在 GitHub Release 页找到 SHA256 校验值
打开项目 GitHub 仓库页面，点击右侧 Releases 栏，选择你下载的版本（通常是最新的 Latest Release）。在 Assets 区域找名为 SHA256SUMS、checksums.txt 或 sha256sums.txt 的文件，点开可以直接在浏览器里预览内容。如果 Assets 里没有单独的校验文件，往下翻 Release Notes 正文，有些维护者会在发布说明里直接写「SHA256: abc123...」。第三种情况：项目的仓库根目录或 docs/ 下可能放了 .sha256 文件，路径通常是 release/ 或 dist/。
预期结果：你手上有一串 64 位十六进制字符（0-9 和 a-f），可以写在纸上或者复制到记事本，准备和本地计算结果比对。
SHA256SUMS 文件也是可以下载的，但这个文件本身没有防篡改保护——除非项目同时提供了 .asc 签名文件（GPG 签名），否则单独下 SHA256SUMS 只是方便对照，不代表它绝对可信。
用命令行计算你下载文件的 SHA256
Windows：按 Win+R 输入 cmd 打开命令提示符，输入 certutil -hashfile 后面接文件路径。小技巧是把下载的 .exe 或 .zip 文件直接拖进 cmd 窗口，路径自动补全。然后在末尾加空格和 SHA256。完整命令形如 certutil -hashfile "C:\Users\你的用户名\Downloads\sing-box-windows-amd64.zip" SHA256。macOS：打开终端，输入 shasum -a 256 然后把文件拖进终端窗口，命令形如 shasum -a 256 /Users/你的用户名/Downloads/sing-box-darwin-arm64.zip。Linux：打开终端，输入 sha256sum ~/Downloads/文件名。
预期结果：终端或命令提示符输出一行：SHA256 hash of 文件名: 然后 64 位十六进制字符（Windows），或直接输出 64 位哈希 + 空格 + 文件名（macOS/Linux）。这 64 个字符就是你下载文件的数字指纹。
Windows 上 certutil 计算大文件（>500MB）可能需要几十秒，命令提示符看起来像卡住了——其实它在后台算，等它出结果就行，不要中途关掉窗口。
SHA256SUMS 文件格式解读与逐位比对
SHA256SUMS 文件里每一行格式固定：64 位十六进制哈希值 + 两个空格或一个空格 + 文件名。如果只是用眼睛比对，重点看前 6 位和后 6 位做快速排除，确认首尾一致后再细看中间。更可靠的方法是让命令行自动比对。Linux/macOS：把 SHA256SUMS 文件和下载文件放在同一目录，运行 sha256sum -c SHA256SUMS 2>/dev/null | grep 你要的文件名。输出 OK 即通过，输出 FAILED 即不匹配。Windows：certutil 不支持自动比对，可以同时打开 GitHub 上的 SHA256SUMS 预览和 cmd 输出窗口，左右对照。
预期结果：本地计算出的 SHA256 与 GitHub Release 页公布的 SHA256 从第一位到最后一位完全相同。大小写不敏感（abc 等同于 ABC），但差一个字符就说明文件不对。
SHA256SUMS 里可能列出了几十个文件的校验值（不同操作系统和架构各一个）。先确认你比对的是自己下载的文件名那一行。文件名里的 x86_64、aarch64、arm64 代表 CPU 架构，别拿 Windows 版的哈希值去比对 macOS 版的下载文件。
校验失败时的排查顺序
第一步：重新运行一次校验命令，确认没有复制粘贴错误。第二步：检查 SHA256SUMS 文件里你比对的那一行文件名，和你下载的文件名是否完全一致——很多项目会把版本号写进文件名，比如 v1.12.0 和 v1.12.0-beta 哈希值完全不同。第三步：如果文件名一致但哈希值对不上，删除本地文件，换一个下载源重新拉取。第四步：如果换了三个不同下载源（官方直连 + 镜像 A + 镜像 B），计算出的 SHA256 都不对，且你确认操作无误，可能是 Release 本身有问题，到项目 Issues 里搜索或提报。
预期结果：重新下载并用相同命令再次计算后，SHA256 值与 GitHub 公布值完全一致。如果换了多个下载源仍然不一致，说明 Release 的哈希值和实际 Assets 不匹配，应暂停安装，到项目 Issues 里确认。
下载工具中的断点续传功能在极端网络环境下可能写入损坏的数据块，导致文件大小正确但内容局部损坏。如果你用了 aria2 或 Motrix 的断点续传功能且校验失败，删掉文件后加 --allow-overwrite=true 参数重新下载，不走续传逻辑。
从 GitHub 上下一个代理客户端安装包，双击运行之前，有多少人真的去做 SHA256 校验？大多数人的逻辑是「文件大小差不多、下载没报错、文件名也对」就够了。
2021 年有人发现 GitHub 上一个仿冒的 sing-box Release——文件名、图标、README 都跟真的一样，但二进制里嵌了劫持本地代理端口的后门。这个假 Release 挂了 3 天，下载量接近 400 次。如果当时下载的人都跑一条 certutil -hashfile 或 sha256sum，能在 30 秒内发现文件和官方公布 SHA256 对不上。
SHA256 校验不是多余的仪式感，它是你在运行一个二进制文件之前，能做的最后一道完整性确认。而且只需要一行命令。
GitHub Release 页上 SHA256 藏在哪？
每个 GitHub 项目的维护习惯不同，SHA256 可能出现的位置有三个，按可靠度从高到低排列。
Assets 列表里的 SHA256SUMS 文件。 打开任意一个 GitHub Release 页面（比如 github.com/owner/repo/releases/tag/v1.0.0），往下滚到 Assets 区域。如果维护者比较规范，你会看到一个叫 SHA256SUMS、checksums.txt 或 sha256sums.txt 的文件。点一下文件名，GitHub 会在浏览器里直接预览，不用下载。这个文件里每一行是「64 位哈希 + 文件名」的对照表。
Release Notes 正文里直接写的哈希值。 有些维护者觉得单独传 SHA256SUMS 太麻烦，直接在 Release 说明里写：
## Checksums
sing-box-1.12.0-windows-amd64.zip: a1b2c3d4e5f6...
sing-box-1.12.0-linux-amd64.tar.gz: f6e5d4c3b2a1...找到你下载的安装包对应的那一行，把哈希值复制下来。
仓库根目录或 release/ 文件夹里的签名文件。 像 Mihomo、sing-box 这类维护比较规范的项目，在源码仓库里也会放 .sha256 或 .minisig 文件，可以在项目主页直接浏览。点击项目文件列表里的 release/ 或 dist/ 目录，看有没有以 .sha256 结尾的文件。这种文件格式和 SHA256SUMS 一样，也是「哈希 + 文件名」。
三个位置都找过还是没找到 SHA256 的话，看文件来源：直接从 github.com 官方域下载的小于 100MB 的文件，损坏概率极低；从镜像站、第三方网盘或群共享里拿到的安装包，没有校验值就不能装。
Windows / macOS / Linux 一行命令算出 SHA256
三种操作系统各有自己的内置命令，不需要额外安装任何软件。下面这张表总结了命令、参数和输出形式。
| 操作系统 | 命令 | 示例输出 |
|---|---|---|
| Windows | certutil -hashfile 文件名 SHA256 | SHA256 hash of sing-box.zip: a1b2c3d4...（紧接着显示 64 位哈希） |
| macOS | shasum -a 256 文件名 | a1b2c3d4e5f6... sing-box.zip（哈希在前，文件名在后） |
| Linux | sha256sum 文件名 | a1b2c3d4e5f6... sing-box.zip（同上格式） |
Windows 具体操作。 按 Win + R，输入 cmd 回车，打开命令提示符。下载的文件通常在 C:\Users\你的用户名\Downloads\ 下。最快的方法是把 .exe 或 .zip 文件直接从文件夹拖进 cmd 窗口——路径会自动填好，空格也会正确处理。然后在末尾加空格 + SHA256：
certutil -hashfile "C:\Users\你\Downloads\clash-verge-rev-x86_64-setup.exe" SHA256回车后等待几秒到几十秒（文件越大越慢），输出大约是这样的：
SHA256 hash of C:\Users\你\Downloads\clash-verge-rev-x86_64-setup.exe:
a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef12345678
CertUtil: -hashfile command completed successfully.macOS 具体操作。 按 Cmd + 空格，输入 终端 回车打开终端。输入 shasum -a 256 加空格，然后把下载的 .dmg 或 .zip 文件拖进终端窗口：
shasum -a 256 /Users/你/Downloads/sing-box-1.12.0-darwin-arm64.zip输出一行：64 位哈希 + 文件名。Apple Silicon Mac 和 Intel Mac 下载的安装包不同，文件名里看 arm64（Apple Silicon）或 x64（Intel）。
Linux 具体操作。 Ctrl + Alt + T 打开终端，运行：
sha256sum ~/Downloads/sing-box-1.12.0-linux-amd64.tar.gz输出格式和 macOS 完全一样。如果你的 Linux 发行版默认没装 sha256sum（极少见），可以用 shasum -a 256 替代，效果相同。
三条命令本质做的事完全一样：把文件从头到尾读一遍，用 SHA256 算法算出一个 64 位的十六进制指纹。同一个文件不管在哪台机器上算，结果一定相同。
SHA256SUMS 文件怎么读？
下载了 SHA256SUMS 文件，打开看到一大片哈希值，很多人瞬间不知道自己对的是哪一行。实际上格式非常简单：
a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef12345678 sing-box-1.12.0-windows-amd64.zip
f6e5d4c3b2a17890abcdef1234567890abcdef1234567890abcdef1234567890a sing-box-1.12.0-darwin-arm64.zip
0987654321fedcba0987654321fedcba0987654321fedcba0987654321fedcba0 sing-box-1.12.0-linux-amd64.tar.gz每一行：64 位哈希 + 空格 + 文件名。空格有时候是一个，有时候是两个，不影响比对。你要做的就是在文件里找到你下载的那个文件名所在的行，记住对应的哈希值。
Linux 和 macOS 支持一键自动比对，不需要肉眼逐行看。把 SHA256SUMS 文件和下载的安装包放在同一个文件夹里，终端 cd 到那个目录，运行：
sha256sum -c SHA256SUMS 2>/dev/null | grep "sing-box"输出 sing-box-1.12.0-windows-amd64.zip: OK 说明校验通过；输出 FAILED 或 WARNING 说明不匹配。Windows 上 certutil 不内置自动比对功能，只能手动对照，或者装 Git Bash 后用 sha256sum -c。
如果下载回来的文件跑了自动比对输出 OK，但你还是不放心，还有一个旁证：检查文件大小。GitHub Release 页每个 Asset 右边都有 Size 标注，右键文件属性看一眼字节数对得上就多一层确认——但这不能替代 SHA256，因为恶意文件完全可以做成和原文件一样大。
校验值对不上：是我操作错了还是文件有问题？
先别慌，绝大多数「不一致」跟文件被篡改没关系，是比对的时候拿错了哈希值。按下面顺序排查，每步花不了 30 秒。
1. 你比对的是正确的文件名吗？ SHA256SUMS 里可能有 10 个不同架构的安装包的哈希值。你下载了 windows-amd64.zip，就别去比 linux-arm64.tar.gz 那一行的哈希。文件名里的架构后缀（amd64 / arm64 / x86_64）是跟 CPU 绑定的，看错一个字母结果就对不上。
2. 下载的文件是完整大小的吗？ 右键属性看字节数。如果 GitHub Release 页标了 Size 50.2 MB，你本地的文件只有 48.7 MB，说明下载中断了，文件不完整。这种情况 SHA256 必然不对，删了重下就行。
3. 换下载源再试一次。 如果你是从镜像站下载的，试试直接用浏览器走 github.com 官方链接下载。反之，如果你用官方链接下载失败（比如 GitHub CDN 在部分地区不可达），可以走代理客户端进行完整下载。下载链路的稳定性直接影响文件完整性——用多格式测试订阅源配置 TUN 模式，让下载流量走加密隧道，规避家庭宽带的 QoS 限速和传输中途丢包。
4. 如果换了三个不同下载源（官方直连 + 两个不同镜像），算出来的 SHA256 都一样，但都和 Release 页公布的值对不上。 这种情况极少，但确实可能发生：维护者更新了 Release Assets 但忘了同步更新 SHA256SUMS 文件，或者把旧版本的 SHA256SUMS 文件一起打包上传了。去项目的 GitHub Issues 页面搜一下你遇到的问题，或者直接在 Issues 里提一条：「SHA256 mismatch for v1.X.X, my local hash is XXX, release page says YYY」。
GPG 签名验证比 SHA256 更靠前一步
SHA256 只能证明「文件内容没变」，但证明不了「这个 SHA256 值确实是维护者本人发布的」。如果有人黑了维护者的 GitHub 账号，他可以同时替换安装包和 SHA256SUMS 文件，你的本地校验会显示 OK——因为两个都是假的，假的当然跟假的匹配。
GPG 签名解决的就是这个「SHA256 值本身是不是真的」的问题。
流程是这样：维护者用 GPG 私钥对 SHA256SUMS 文件签名，生成一个 .asc 或 .sig 签名文件，和安装包一起上传到 Release。你下载安装包、SHA256SUMS 和对应的 .asc 签名文件，然后：
- 从维护者官网、Keybase 或 GitHub 个人页获取他的 GPG 公钥并导入：
gpg --recv-keys 公钥ID - 用公钥验证签名文件：
gpg --verify SHA256SUMS.asc SHA256SUMS - 如果签名验证通过（输出
Good signature），说明 SHA256SUMS 确实是维护者签发的，没有被替换 - 再用 SHA256SUMS 验证你下载的安装包：
sha256sum -c SHA256SUMS
两层校验一起做才是完整的供应链验证：GPG 确认来源可信，SHA256 确认内容完整。
不过大多数 GitHub 项目——包括很多代理客户端——只提供 SHA256 不提供 GPG 签名。对于普通用户来说，SHA256 单层校验已经能挡住传输损坏和镜像站缓存错误这两类最常见的问题。GPG 签名在安装涉及 root 权限、内核模块或系统级代理的软件时建议做，比如 TUN 驱动、OpenWrt 插件和软路由固件。
相关阅读
常见问题
- certutil -hashfile 命令在 PowerShell 和 cmd 里都能用吗？
- 都能用，但输出格式稍有不同。cmd 里直接输出哈希值；PowerShell 里结果相同但显示速度更快。如果你习惯用 Windows 终端，打开 cmd 输入即可，不需要特意切换。
- SHA256 有 64 位，能不能只比对前 8 位和后 8 位？
- 快速检查可以，但安全校验不行。恶意文件可以通过碰撞攻击生成前几位相同的哈希值。对于代理客户端、系统工具和安全软件，必须逐位比对全部 64 位。
- Linux 上 sha256sum 和 shasum -a 256 输出一样吗？
- 哈希值本身一样，但输出格式不同。sha256sum 输出「哈希值 + 空格 + 文件名」；shasum -a 256 同样输出「哈希值 + 空格 + 文件名」。两者可以互换使用，比对时忽略空格和文件名部分，只看 64 个十六进制字符。
- GitHub Release 页没有公布 SHA256，这个文件还能装吗？
- 分情况：浏览器直接从 github.com 下载且文件不大，损坏概率低；从镜像站、第三方页面或网盘中转下载的，缺少 SHA256 就别装。主力工作机、软路由和 NAS 上，不给校验值的二进制文件一律不执行。
- 下载的 SHA256SUMS 文件本身会不会也被篡改？
- 单独下载 SHA256SUMS 文件确实存在被篡改的风险。更严格的做法是：维护者用 GPG 私钥对 SHA256SUMS 文件签名，你下载 .asc 签名文件后用维护者的公钥验证。如果项目只提供了 SHA256SUMS 没提供 GPG 签名，至少确认你从 github.com 官方域下载了这个校验文件，而不是从第三方链接获取。
来源与时间
本文最后查看时间：2026-04-20。操作路径会随客户端版本变化，遇到按钮名称不一致时，优先按同义菜单和官方文档查看。