第3章 CRC多项式选择：常见多项式（CRC-8, CRC-16, CRC-32等）
说实话，CRC多项式选型这事儿，很多新手觉得不就是随便找个多项式算一算吗？但我做了十几年嵌入式通信，得告诉你——多项式选错了，你的系统可能在特定干扰下疯狂丢包。我就吃过这个亏。
这一章我们把最常用的CRC多项式扒开来看看。你不光要记住它们的名字，更要理解：为什么这个多项式适合这种场景？学会了选型逻辑，以后你自己也能根据设计需求挑多项式。
3.1 CRC多项式到底是个什么玩意儿？
CRC多项式本质上是一个二进制除法中的除数。你发送的数据看作一个巨大的二进制数，双方约定同一个除数去做除法，余数就是CRC校验值。多项式选得好不好，直接决定了你能检出多少种错误。
嗯，这里要注意一点：多项式用十六进制表示时，通常写的是去掉最高位(MSB)之后的简化形式。比如CRC-8标准多项式0x07，实际二进制是100000111（9位），但写出来省略了最高位的1。我见过有工程师查表的时候用0x07直接去做多项式除法，结果算出来死活对不上——其实就是忘了补这个隐式的高位1。
3.2 常用多项式一览表
我把工程中最常见的那几个多项式整理成了表格。你用的时候可以直接对照。
| 名称 | 多项式（十六进制） | 二进制生成多项式（8/16/33位） | 典型应用场景 |
|---|---|---|---|
| CRC-8 | 0x07 | 100000111 | 1-Wire、SMBus、简单传感器 |
| CRC-8-Dallas | 0x31 | 100110001 | DS18B20等Dallas温度传感器 |
| CRC-16-CCITT | 0x1021 | 10001000000100001 | Modbus、XMODEM、蓝牙、NFC |
| CRC-16-USB | 0x8005 | 10000000000000101 | USB数据包、SD卡协议 |
| CRC-16-IBM | 0x8005 | 10000000000000101 | 老式异步通信、ISO/IEC 13239 |
| CRC-32 | 0x04C11DB7 | 100000100110000010001110110110111 | 以太网、GZIP、ZIP、PNG、FAT32 |
| CRC-32C (Castagnoli) | 0x1EDC6F41 | 1111011011100000110111101000001 | iSCSI、SCTP、存储阵列（性能更优） |
| CRC-64-ECMA | 0x42F0E1EBA9EA3693 | （省略） | 大数据校验、文件系统（ZFS） |
表中同一个CRC-16可以用不同多项式吗？可以。比如0x8005和0x1021就分别被IBM和CCITT采用。我建议你：如果做Modbus协议就老实选0x1021，别自己折腾别的多项式——互操作性会出问题的。
3.3 怎么选？三个维度来判断
3.3.1 数据长度决定多项式位数
CRC校验值的位数直接决定了它能覆盖的最大数据长度。为什么？你想想看，CRC本质上是模2除法，多项式次数越高，余数空间越大，碰撞概率越小。
- CRC-8：适合1～128字节的数据包。我见过有人用CRC-8校验256字节的Modbus帧，结果误码漏检率达到不可接受的水平。别省那一个字节的开销。
- CRC-16：适合128字节～4KB的数据块。Modbus RTU最长256字节，CRC-16足够了。
- CRC-32：任意长度。理论上可覆盖2^32 -1位的消息，实际以太网帧到1500字节，CRC-32的漏检率极低。
经验数据：当消息长度超过4KB时，CRC-16的漏检率会明显劣化。我在项目中遇到过磁盘阵列的SAS链路用CRC-16校验大数据块，结果偶尔出现被污染的帧通过了校验——换成CRC-32C后问题消失。
3.3.2 误码检测能力——多项式的“质量”
不是随便一个n次多项式都能检测同样的错误。好的多项式必须满足：
- 本原多项式（Primitive Polynomial）——能生成最大周期的LFSR序列，检测所有奇数个错误和所有单比特错误。
- 低重量项少——生成多项式中系数为1的项不能太少。比如0x03只有3个1，适合短数据，但对长数据检错能力弱。CRC-32有多个1，更“稠密”。
- 能检测突发错误——CRC可以检测长度不超过多项式次数的所有突发错误。例如CRC-16能检测所有≤16位的突发错误。
选型技巧：如果你不打算深究数学，直接使用国际标准中已经验证过的多项式。比如CRC-32的0x04C11DB7经过了30年工业验证，没有“埋坑”。我曾经遇到过工程师自己发明了一个32次多项式，自测没问题，但上线后在特定干扰模式下漏检率高得吓人。
3.3.3 实现开销与速度
CRC可以用硬件LFSR也可以用软件查表。在嵌入式MCU上，查表法是最常见的。
- CRC-8：查找表256字节，速度极快，适合低功耗传感器。
- CRC-16：查找表512字节，兼顾性能与存储。
- CRC-32：查找表1024字节（按字节算），代码体积稍大，但现代ARM内核完全吃得消。
- CRC-32C：查找表同样1024字节，但用Castagnoli多项式在某些CPU上有硬件加速指令（如Intel SSE4.2）。
注意：不要在一颗只有2KB RAM的8位单片机里用CRC-32的查表法。我曾经在STM8上这么干过，结果RAM直接炸了。改用CRC-16查表，外加半字节查表（16字节表）才勉强跑通。
3.4 三种场景下的选型实战
咱们结合真实场景来走一遍选型判断。
场景A：温度传感器节点（8位MCU，无线发送12字节数据）
- 推荐：CRC-8-Dallas（0x31）
- 理由：数据短，CRC-8检错能力足够。0x31是本原多项式，能检测所有奇数位、1～2位错误。查找表256字节，不到100个子节。
- 备选：CRC-8-ATM（0x07），但0x07不是本原多项式，对双比特错误检测稍弱。
场景B：工业Modbus RTU总线（RS-485，主站与从站交换128字节以内的寄存器值）
- 推荐：CRC-16-CCITT（0x1021）
- 理由：Modbus协议强制规定用这个多项式，不能改。它的检错能力覆盖了工业现场的典型干扰。
场景C：板级高速数据采集（FPGA采集ADC数据，通过UDP发送，每包1460字节）
- 推荐：CRC-32（0x04C11DB7）
- 理由：数据量大，需要极低漏检率。CRC-32能检测所有≤32位的突发错误。FPGA里可用并行计算或流水线。
- 进阶：如果FPGA支持硬件CRC-32C，可以换CRC-32C，因它有更好的随机错误检测性能。
3.5 多项式初始值与出值后处理
选定了多项式还不够，还要约定初始值和异或出值。这两个参数会影响CRC计算结果。
| 参数 | 常见值 | 作用 |
|---|---|---|
| Init | 0x0000 / 0xFFFF / 0xFFFFFFFF | 初始LFSR状态；0xFFFF可额外保护前导零 |
| RefIn | True / False | 是否将输入字节的位序反转（很多串行协议需要） |
| RefOut | True / False | 是否将输出CRC的位序反转 |
| XorOut | 0x0000 / 0xFFFF / 0xFFFFFFFF | 最终CRC是否异或固定值 |
举个例子：CRC-32的标准参数是Init=0xFFFFFFFF, RefIn=True, RefOut=True, XorOut=0xFFFFFFFF。如果你和我一样用Python的zlib.crc32()算出来的结果，和手册对不上——十有八九就是参数差异。
避坑指南：我曾经用一个开源CRC32查表库算出来的校验值与以太网卡算的不一致。查了一整天，最后发现库用的Init是0x0000，而标准以太网用0xFFFFFFFF。改过来就通了。所以用多项式的时候，一定把全套参数都定义成宏，方便调试。
3.6 回顾：一张表搞定选型决策
我觉得你可以把这张表打印出来贴在工位上。
| 数据长度 | 推荐CRC | 多项式（Hex） | 典型应用 |
|---|---|---|---|
| ≤128字节 | CRC-8 | 0x07 | 单总线传感器 |
| ≤4KB | CRC-16 | 0x1021或0x8005 | Modbus、USB |
| 任意长度 | CRC-32 | 0x04C11DB7 | 以太网、存储 |
| 高性能需求 | CRC-32C | 0x1EDC6F41 | iSCSI、存储阵列 |
好了，多项式选型的底子就搭完了。下回你看到一块硬件的CRC配置，不仅能看懂多项式，还能分析出设计者为什么要用这个。做到这一步，你就跟那些“随便粘个CRC库”的工程师拉开了差距。下一步，咱们该动手写代码实现查表法了。