校验原理概述：哈希算法、CRC与校验和

做固件这么多年，我遇到过最头疼的问题之一，就是镜像烧进去之后设备跑飞了。到底是传输过程中数据变了，还是存储介质坏了？这时候，校验机制就是你手里最趁手的工具。说白了，校验就是给数据算一个「指纹」，用这个指纹来判断数据有没有被篡改或损坏。

这一章，我把三种最常用的校验方法掰开揉碎了讲。你不需要成为密码学专家，但得知道它们各自能干什么、不能干什么。

哈希算法，也叫散列算法。它的核心思想是：不管输入多长，输出固定长度。而且输入稍微变一点点，输出就天翻地覆。你想想看，这特性用来做固件校验再合适不过了。

MD5 输出 128 位，也就是 16 个字节，通常用 32 个十六进制字符表示。我在早期项目里用过很多次，但后来发现它有个致命问题——碰撞。什么意思？就是你能找到两个不同的文件，算出来的 MD5 值一模一样。

⚠️ 注意：MD5 已经不再安全。在安全敏感的场景下（如 OTA 升级包签名验证），绝对不要只用 MD5。我见过有人因为偷懒继续用 MD5，结果被攻击者伪造了镜像，整批设备都得召回。

SHA 系列是 MD5 的升级版。目前主流的是 SHA-256，输出 256 位，32 个字节。碰撞概率极低，目前还没有实际可行的攻击方法。

💡 我的建议：新项目直接上 SHA-256。资源受限的 MCU 可以用硬件加速模块，很多 Cortex-M 系列芯片都内置了 SHA 引擎，算起来很快。

CRC（循环冗余校验）跟哈希算法不一样。它不是用来防攻击的，而是用来检测传输或存储中的随机错误。比如 UART 通信、Flash 读取、网络包传输，这些场景下 CRC 是标配。

CRC 的原理，说白了就是多项式除法。发送方把数据当作一个巨大的二进制数，除以一个约定的多项式，余数就是 CRC 值。接收方用同样的方法算一遍，如果余数不为零，说明数据出错了。

我记得有一次排查一个 SPI Flash 读取偶尔出错的问题，就是靠 CRC 定位到的。数据在读取路径上被时钟抖动干扰了，CRC 值对不上，一查一个准。

关键点：CRC 能检测出所有奇数个错误、所有突发长度小于等于 CRC 宽度的错误。对于随机比特翻转，CRC-32 的漏检率大约是 2^-32，非常可靠。

校验和是最简单粗暴的校验方式。就是把所有数据字节加起来，取低 8 位或 16 位作为校验值。实现起来几行代码就搞定，但它的检错能力也是最弱的。

举个例子，如果两个字节同时出错，一个加 1，一个减 1，总和不变，校验和就检测不出来。我在一个早期项目中用过校验和做 Bootloader 的镜像校验，结果有一次 Flash 的某条数据线虚焊，导致连续两个字节都错了，校验和愣是没发现。从那以后，我再也不敢在关键路径上只用校验和了。

我把它们放在一起对比一下，你一眼就能看出区别。

特性	校验和	CRC	哈希（SHA-256）
输出长度	8/16 位	8/16/32 位	256 位
计算速度	极快	快	较慢
检错能力	弱	强	极强
抗碰撞	无	有限	强
典型用途	简单完整性检查	传输错误检测	安全校验、签名

下面这张图把三种校验方式的关系和适用场景梳理清楚了。

讲完了原理，说说我在实际项目中怎么选。

💡 一个实用技巧：在 Bootloader 里，我通常先用 CRC 快速校验整个镜像，确认没有传输错误。然后再用 SHA-256 校验签名，确认镜像没有被篡改。两层校验，各司其职，既不慢又安全。

嗯，校验原理这块就讲这么多。你把这些基础打牢了，后面排查校验异常的时候，才能一眼看出问题出在哪个环节。