为什么要校验
下载安装包、系统镜像时，官方通常会公布 SHA-256 值。比对它能确认两件事：文件在传输中没有损坏，以及没有被篡改（例如被植入恶意代码）。
三步完成
- 在官方页面找到公布的 SHA-256 值——别拿成 MD5 或 SHA-1 的值去比。
- 用工具计算你手上这份文件的 SHA-256。
- 逐字符比对，完全一致才算通过。
最常见的三个坑
- 算法对不上：官方同时给了 MD5 和 SHA-256，你比错了那一个。
- 文件来源不可信：下载页面被劫持时，公布的值也是假的。尽量走 HTTPS 官方源。
- “差不多就行”：哈希必须逐字符完全一致，差一个字符都说明文件不同。
在浏览器里本地计算
使用浏览器 Web Crypto 计算哈希，文件全程不上传：既快，也不会把内容暴露给第三方。大文件耗时与体积成正比，耐心等待即可。
各系统命令行速查
| 系统 | 命令 |
|---|---|
| Windows（PowerShell） | Get-FileHash .setup.exe -Algorithm SHA256 |
| Windows（CMD） | certutil -hashfile setup.exe SHA256 |
| macOS | shasum -a 256 setup.dmg |
| Linux | sha256sum image.iso |
哈希校验 vs 数字签名
哈希只能证明“文件没变”，不能证明“文件来自官方”——校验值本身就写在官网上，官网被篡改时校验会一起失效。数字签名（GPG 签名、代码签名证书）用私钥签名、公钥验证，能同时证明完整性与来源。系统镜像、软件包这类高风险下载，应优先核对签名。
校验失败但文件能用，怎么排查
- 确认官方值对应的是哪个文件——同名文件常有多个版本或架构（x64 / arm64）；
- 确认下载完整，没有被浏览器或代理截断（对比文件大小）；
- 确认比对时没有多带空格、换行或大小写差异；
- 以上都排除仍不一致 → 不要安装，换官方源重新下载。
批量与自动化
需要校验多个文件时，把「期望哈希 + 文件路径」整理成清单，用脚本逐条计算并比对，输出通过/失败列表，避免人工逐条比对出错：
# values.txt 每行：期望哈希 + 文件路径
while read -r expect file; do
actual=$(sha256sum "$file" | awk '{print $1}')
[ "$expect" = "$actual" ] && echo "OK $file" || echo "FAIL $file"
done < values.txt对于持续交付的场景，建议在构建产物生成时就输出哈希清单，并在部署前自动比对，把校验前移到发布流程里。
动手试试：文件哈希校验（拖入文件自动计算）、哈希计算（文本哈希）
校验流程的组织方式
校验的价值取决于是否形成流程，而不是单次执行。
- 发布方与使用方各持一份：校验值应与文件分开传递，例如发布在官网公告页而不是与文件放在同一目录，避免同时被替换而失去意义。
- 在构建阶段生成：校验清单应由构建流程自动产出并随版本归档，手工计算的校验值极易出错且难以复现。
- 把校验前移到部署：部署脚本在下载后自动校验，不匹配就中止，而不是等到运行时报出难以理解的错误。
- 记录校验结果：把校验通过与失败都记入日志与监控。持续的失败往往意味着镜像站不同步或中间链路被篡改。
- 定期抽查：对长期未更新的产物定期抽查一次，确认归档文件没有在存储层面被损坏或替换。
与签名的区别
校验值解决的是“文件是否与预期一致”，签名解决的是“发布者身份是否可信”。二者常常配合使用：先用公钥验证签名确认来源，再用校验值确认内容完整。只做其中一项，都可能在供应链攻击面前失效。
归档场景的补充建议
长期归档还应定期做一次完整性巡检：把归档文件的校验值与当初记录的值比对，能提前发现存储介质老化或迁移过程中的损坏。巡检频率可按介质可靠性与数据价值设定，低成本存储也不应完全跳过这一步。