下载完发现哈希对不上，先别急着重下

上周帮同事处理一台办公电脑，下载现哈希对先别他盯着屏幕念给我听：“校验失败，不上文件可能已损坏。重下”桌面上摆着一个刚下完的下载现哈希对先别安装包，旁边浏览器标签还开着下载页。不上他的重下第一反应是按 F5 重新下载，第二反应是下载现哈希对先别把杀毒软件关掉再试一次。我让他先停下——这两步都是不上把问题往后拖，而不是重下解决。

哈希校验这件事，下载现哈希对先别出错时的不上正确方向往往不是“再试一遍”，而是重下先判断自己有没有走错路。反复失败时继续加动作，下载现哈希对先别只会把变量搅得更多。不上下面按“停手—回退—换人”的重下顺序说，场景围绕已经出错之后怎么收场。

先把“重下”这个按钮按住别点

很多人一看到哈希值不一致就重下，下完再算，还是不一致，于是开始怀疑网络、怀疑硬盘、怀疑人生。问题在于：重下只改变“文件”这一个变量，而校验失败可能是四个变量里的任意一个——文件本身传坏了、你算的方式不对、你比的那串值来源不对、工具默认用了别的算法。

比如 Windows 上有人用 certutil -hashfile 文件名 SHA256，却拿它去和发布页给的 MD5 值比，长度都不一样，当然对不上。也有人用 PowerShell 的 Get-FileHash 不写 -Algorithm，默认走 SHA256，结果发布方只提供 SHA1。这种“对不上”不是文件坏了，是两边不在同一套规则里。

所以第一步是停：把当前算出的值、用的命令、对比的那串值的出处，原样抄到记事本里。抄完再看一眼——两个值的字符数一样吗？一个是 64 位十六进制，另一个是 32 位，那就不是同一算法，重下一百次也没用。

回退到“值的出处”，而不是回退到下载按钮

哈希校验适合什么场景，往往在出错时才看得清楚：它适合“来源可信、值可追溯”的场合，比如从官方发布页拿到的安装包、镜像站公布的校验清单、软件仓库里随包附带的签名文件。反过来，如果那串哈希值是从论坛回帖、聊天记录、二手网盘说明里抄来的，它本身就不具备比对资格。

我见过一个典型反例：有人从第三方下载站拿了一个压缩包，页面底部贴着一行 SHA-256，算完对不上，于是反复重下。后来发现那行值是上一个版本的，页面没更新。这种情况下，回退的对象不是下载动作，而是“值的出处”——回到软件官方站点或项目仓库的 release 页面，找与当前版本号对应的校验值。找不到，就承认这一环没有可信参照，别硬凑。

核对顺序可以按这个来：

一、安装包内或同目录是否有 .sha256、.md5、.sig 之类的文件，优先用它；
二、官方发布页或仓库 release 说明里的值，注意版本号和文件名要完全对应；
三、镜像站、分发页的值，只能作为辅助，冲突时以上游为准；
四、论坛、聊天记录、网盘备注里的值，不参与放行判断。

如果前两类都拿不到，正确的做法是换获取渠道，而不是换算法去凑一个“看起来对”的结果。

算出结果不一样时，换人比换工具更有效

“换人”在这里有两层意思。一层是换执行的人：如果你已经重下两次、换过算法、换过工具，仍然对不上，让另一个同事用他自己的机器、自己的网络、自己的命令算一遍。这一步能快速区分是文件问题还是你这台环境的问题——比如你的下载被代理缓存了旧版本，或者你的 certutil 输出带了多余字符。

另一层是换判断的人：如果这个文件要用于正式环境，比如装到服务器、发给客户、作为归档留存，而校验值始终无法与可信来源对齐，那就别自己拍板放行。交给负责发布或采购的同事，让他们去和提供方确认版本。哈希校验的价值在于“可比对”，不在于“能算出来”；算得出但对不上来源，等于没校验。

还有一种情况容易被忽略：文件能正常打开、安装也成功了，但哈希对不上。这时不要用“能用就行”说服自己。能打开只说明格式没坏，不说明内容没被替换。是否放行取决于这个文件的用途——个人临时试用和正式分发，容忍度完全不同。

把这次冲突记成三行，下次少走一圈

处理完之后，留一条记录，不用长，三行够：第一行写文件全名和版本号；第二行写你用的算法和命令；第三行写比对值的出处，以及最终是“一致放行”“不一致已弃用”还是“无可靠来源，改用官方渠道”。

这条记录的作用不是交差，是下次遇到同类文件时，你能一眼看出该信哪里。哈希校验适合什么场景，答案其实很朴素：适合有明确发布方、有版本对应关系、有可追溯清单的场合；不适合拿来历不明的字符串当裁判。已经做错的时候，停手比补救重要，回退到出处比回退到下载按钮重要，换个人复核比换十个工具重要。