下载完顺手校验，别被那些老说法带偏

先给一条能当场核对的下载判断标准：如果你手里的校验值来自和文件同一个页面、同一封邮件、完顺同一个下载按钮旁边的手校文字，那它只能证明“传输没断”，验别证明不了“文件没被人换过”。被那真正有意义的老说校验，是法带拿一个独立渠道公布的摘要去比对。这条标准一摆出来，下载很多流传很广的完顺说法就站不住了。

关于哈希校验的手校过时说法，最常见的验别两类是“MD5 够用，快就行”和“校验值对得上就绝对安全”。被那这两种做法背后其实是老说两种不同的使用场景，选错了后果不一样，法带得并排看清楚。下载

场景一：只防传输损坏，MD5 或 CRC 仍能干活

先说适用边界。你从公司内网盘拉一个 2GB 的镜像，或者从 U 盘往另一台机器拷设计稿，担心的是线缆接触不良、拷贝中断、扇区读错。这种场景下，文件内容没有敌对者插手，目标只是发现“比特有没有翻车”。此时 MD5 甚至 CRC32 都还能用，速度快、工具多，Windows 自带的 certutil -hashfile 文件名 MD5 一行就出结果。

代价要交代清楚：MD5 和 SHA-1 早就被证明能构造碰撞，也就是两段不同内容可以算出同一个摘要。所以它们只适合“非对抗环境”。什么叫非对抗？文件来源是你信任的内部系统，中间没有人有动机去替换它。一旦文件要经过公网、第三方网盘、陌生人的邮件附件，这个前提就没了。

选错的后果很具体：你以为自己做了校验，其实只是确认了“下载过程没掉包”，而真正被替换的文件照样能通过。更麻烦的是心理上的假安全感——出了事回头一看，校验记录齐全，却证明不了任何事。

场景二：要防篡改，摘要必须来自独立渠道

第二种做法是拿 SHA-256 之类的强摘要，并且刻意从另一个渠道获取。比如你在官网下载页拿到安装包，摘要去官方文档站或发布公告里核对；开源项目则看签名标签或发布说明，而不是下载页上那串跟着文件一起滚动的字符。

这里的边界是：算法强不等于流程强。SHA-256 目前没有实用的碰撞攻击，但如果摘要和文件躺在同一个被攻破的服务器上，攻击者两边一起改，你比对得再认真也没用。所以判断点不在“用没用 SHA-256”，而在“摘要和文件是不是同源”。同源即失效，这是很多人忽略的一步。

另一个容易踩的细节是比对方式。摘要是一长串十六进制，肉眼比对容易看花。稳妥的做法是用工具算完直接做字符串比较，或者至少核对首尾各若干位。手工逐字符对，出错概率不比不校验低多少。

还有一种过时说法是“有哈希就不用看数字签名”。这两件事解决的不是同一个问题：哈希校验确认内容完整，数字签名确认“是谁发布的”。对普通文档，摘要够用；对可执行程序、系统镜像、自动更新包，签名才是防替换的关键一环。预算和精力有限时，先保签名，再谈摘要。

把两种做法放进同一张对照里

可以这样记：内部搬运、排查坏文件，用快摘要，图的是效率；跨网络分发、安装可执行文件，用强摘要加独立来源，图的是可信。前者选错成后者，浪费时间和带宽；后者选错成前者，等于没防。

实际操作时，我会先问三个问题：文件从哪来、中间经过谁、坏了会怎样。三个答案都指向“自己人、内网、重下即可”，MD5 或 CRC 完全够。只要有一个答案指向“公网、第三方、装到生产机”，就换成 SHA-256，并且把摘要来源单独确认一遍。关于哈希校验的争论，多半是没把这两个场景分开谈。

最后留一个可核对的习惯：保存校验记录时，连同摘要的来源地址和获取时间一起记下来。下次有人问“这个值哪来的”，你能答得上，校验才算真正闭环。工具命令和算法名称会变，这个习惯不会过时。