软件实现CRC时为何存在MSb到LSb、LSb到MSb两种变体？

核心原因从来和“适配硬件传输位序”的表层原因无关，本质是生态惯性、平台性能、结果匹配成本三个实际因素共同决定的：

• 生态与协议兼容性是首要前提
  CRC算法的第一要求是跨实现的计算结果完全一致，不存在脱离具体协议定义的“通用正确CRC”。大量早于软件CRC标准化的通信、存储协议在制定时就已经绑定了位序规则：比如Modbus RTU、USB等协议从第一版开始就规定使用LSB序的反转CRC，而PNG、ZIP、以太网帧校验则固定使用MSB序的常规CRC。这些协议的生态已经运行了几十年，所有存量设备、抓包工具、校验逻辑都沿用最初的位序定义，软件实现根本没有随意更换位序的空间——哪怕你觉得某一种位序的代码写起来更顺，算出来的结果和存量设备对不上，就没有任何实用价值。
• 两种位序的查表实现在不同CPU架构上各有性能优势
  按字节处理的CRC本质是预生成256项的查表，把逐位移位的开销换成一次查表操作，但查表逻辑本身是和位序强绑定的，不存在“按字节处理就不需要考虑位序”的说法：
  • MSB序（左移）实现中，查表索引由CRC寄存器最高8位与当前输入字节异或得到，核心计算逻辑为crc = (crc << 8) ^ crc_table[((crc >> (WIDTH-8)) ^ data_byte) & 0xff]，取出表项后将寄存器左移8位再异或表项即可，整个过程不需要额外的位反转操作，在天生大端序、左移/高位操作流水更优的架构（比如早期PowerPC、部分8位工业单片机）上，执行周期更少。
  • LSB序（右移）实现中，查表索引由CRC寄存器最低8位与当前输入字节异或得到，核心计算逻辑为crc = (crc >> 8) ^ crc_table[(crc ^ data_byte) & 0xff]，取出表项后将寄存器右移8位再异或表项即可，在x86等天生小端、右移操作效率更高的架构上，加上很多外设输入的字节本身就是LSB在前，连输入字节的位预处理步骤都能省掉，实际性能反而优于MSB序实现。
    两种实现都不需要插入额外的位反转指令，性能表现完全由目标平台的指令集特性决定，不存在某一种是“硬件专用”的说法。
• 结果位序的匹配成本直接决定实现选型
  CRC计算完成后需要拆成字节嵌入到数据帧中传输：如果协议规定LSB先发，你硬要用MSB序计算，得到的32位/16位CRC结果需要做全字位反转、字节序反转才能符合帧格式要求，在没有专用位反转指令的老旧嵌入式CPU上，这个反转操作的开销甚至比直接用LSB序计算整个CRC的开销还高；反过来如果协议规定MSB先发，用LSB序计算同样要额外做结果反转，纯属于无意义的性能损耗。

一个常见误区是：反转多项式/ LSB序实现只是为了适配硬件串行接口。实际上软件实现选择哪种位序，从来不是看实现跑在硬件还是软件上，判断标准永远是两个：能不能和协议规定的校验值100%对齐，能不能在目标运行平台上把开销降到最低。

内容的提问来源于stack exchange，提问作者Guillaume Petitjean