校验和回答的问题
校验和只回答一个问题：刚下载的这个文件，和发布方做出来的那个文件是不是同一个。哪怕只差一个字节，哈希值也会完全不同，所以两边一致就说明传输过程中没有缺失，中途也没有被换成别的文件。值对不上不是小事，不要打开它，重新下载一遍；如果第二份还是对不上，就换个来源。
公布的哈希值放在哪里
多数项目会在下载链接旁边放一个名叫 SHA256SUMS 的文件，每个发布文件占一行。GitHub 的发布页通常把这些值写在发行说明里，或者作为附件上传；Linux 发行版会把它放在和 ISO 同一个目录下。容器镜像则由仓库直接给出以 sha256: 开头的摘要。
哈希值和文件来自同一处时，证明力会打折
如果文件和哈希值都从同一台服务器取得，那么能替换文件的人，也能顺手改掉那个哈希值，两边照样严丝合缝。所以正经项目会给校验和文件加签名：SHA256SUMS 旁边还有 SHA256SUMS.gpg 或 SHA256SUMS.asc，而签名用的密钥另行公布。先验签名，再相信里面的校验和。要是没有签名，那么从别的渠道拿到的值就比躺在文件旁边的值可靠得多，比如项目的邮件列表、软件包清单、厂商的文档站点。
MD5 和 SHA-1 为什么还在
就安全性而言，这两个算法已经被攻破：构造出两个 MD5 相同的不同文件是可行的，SHA-1 的碰撞也在真实文档格式上被演示过。所以它们都无法证明没有人动过手脚。不过发现意外的本事还在，比如中断的下载、坏掉的磁盘、返回旧副本的镜像。不少老项目只公布 MD5，能比一下总好过什么都不比。如果同时给了 SHA-256，就用后者。
为什么写法各家不同
摘要说到底只是一个数，各家写法自然不一样。有的用小写十六进制，有的用大写，因为是同一个值，这里不区分大小写。仓库会像 sha256: 这样把算法名写在前面。sha256sum 命令先输出哈希，再是两个空格和文件名；openssl dgst 则把文件名写在前面，等号之后才是哈希。以上任何一种形式都可以整行粘贴进来，工具会自己把哈希挑出来。