企业官网建设流程全解析

上个月给产线调一套自研的以太网温湿度传感器，节点每5秒通过UDP上报一次温度、湿度和状态字，帧尾带了CRC16。刚开始联调一切正常，后来把样机挪到配电柜边上，接收端就开始间歇性报校验错误。第一反应是现场电磁干扰，于是示波器、网线、电源查了一圈，最后发现问题根本不在干扰，而在CRC本身——发送端和接收端用的虽然都叫"CRC16"，但参数族完全不是一回事。这种锅在实际工程里太常见了，所以把这次选型、实现和排查的过程完整复盘一遍，希望能帮正在做传感器通信或者以太网报文的同行少走点弯路。

这篇文章围绕CRC16和CRC32在以太网温湿度传感器通信里的选型、代码实现和踩坑展开，适合刚入门嵌入式通信的新手，也适合正在做协议设计、数据帧封装的工程师。看完你会明白CRC参数族是怎么一回事，传感器帧里CRC到底该放哪、按什么字节序放，以及真出了问题该怎么一步一步定位。

1. 传感器丢数据的那个下午：为什么以太网里还得自己挂一层CRC

1.1 一台传感器上报的湿度忽高忽低

先还原一下现场。设备结构并不复杂：STM32F103采集SHT30温湿度，经过一个W5500硬协议栈芯片把数据打包成UDP报文发出去。上位机收到后，先查CRC，再解析温度、湿度。刚上电时一切正常，跑了半小时后开始出现零星错误包，频率不高，大约每1000包里有1到2包CRC不对。这种偶发问题最折磨人，因为不好复现，抓包也不一定抓得到。

后来用网络调试助手把接收到的原始UDP负载存成文件，再写脚本离线分析。脚本把每帧的十六进制打印出来，我发现出错的帧非常"规律"：凡是温度或者湿度的高字节恰好是0xFF时，校验就挂。看到这个规律，脑子里嗡了一下——这不是随机干扰，这是发出去的CRC和收回来对不上的系统性问题，只是在某些数据组合下才暴露出来。

顺着这个规律查发送端代码，发现发送端用的查表法是普通模式，而接收端用的是Modbus反转模式。两边都叫"CRC16"，参数却不一样，自然对不上。温度湿度数据里若没有0xFF字节，两种算法恰好算出一致的值，一旦高字节变成0xFF，结果立刻分叉。这个案例特别典型，它说明了一个基础但重要的道理：CRC不是一个单一算法，而是一个带参数的函数家族。

1.2 以太网协议栈看起来可靠，但应用层校验不可省

很多人会问：以太网帧本身有FCS校验，TCP有16位校验和，UDP也带一个可选的校验和，为什么还要在应用层自己做CRC？

这个问题我在现场也被问过。答案是：协议栈的校验和我们的校验覆盖的不是同一段路程。以太网帧尾的FCS是MAC硬件生成、硬件校验的，它只能保证数据在"相邻两个网络设备之间"传输时没出错。可一个UDP报文从传感器到上位机，中间要经过交换机、路由器、Wi-Fi网桥、虚拟化平台，每一跳都会重新生成新的FCS，链路上的任何一跳出错，FCS都能查出来，没错。但问题在于：中间设备如果转发逻辑本身有bug，或者在虚拟化环境下被多次内存拷贝、DMA搬运，数据可能被改写后又被重新封帧，这时候链路层校验就失效了。

TCP的校验和是很多工程师的另一个误解点。TCP和IP头里的校验和用的是ones complement checksum，也就是把数据按16位一组取反求和。这个算法能发现一些简单的翻转，但检测能力远不如CRC。再加上很多传感器节点为了省资源和降低功耗，走的是UDP，UDP校验和在IPv4下还是可选的，很多嵌入式协议栈默认就没开UDP校验和。这意味着报文数据域在传输过程中出了错，上层完全无感。应用层再挂一层CRC，是成本最低、最靠近数据消费方的最后一道保险。

1.3 温湿度数据的特点：错误传播后的"合理假象"

再说一个温湿度传感器特有的坑。温度和湿度数据在帧里通常是16位整数，温度还带符号。比如温度用int16_t存储，单位0.1℃，35.6℃就是356。这个数值在内存里是0x0164。但如果某个字节因干扰变成0xFF，解析出来可能变成-10.0℃或65535那样的值。这种错误比较明显，上位机加个范围判断就能过滤掉。

真正可怕的是另一种情况：错误位让数值仍然落在合法范围内。比如湿度50.0%RH是500，也就是0x01F4，假如高字节0x01被改写成0x02，数据变成0x02F4，也就是75.6%RH，依然是一个"合理"的湿度值。如果没有CRC兜底，上位机识别不出这是坏数据，会把假数据存进历史库，后面做统计报表、联动空调系统时就会抱着一堆假数据跑。所以做传感器通信时，CRC校验的意义不只是"发现错误"，更是在源头保证进入业务系统的每一个样本都是可信的。这也是为什么我坚持在应用层帧里加CRC，哪怕以太网协议栈已经做了一轮校验。

2. CRC16还是CRC32：一言难尽的选型账

2.1 从多项式、初始值到反射：CRC参数家族

CRC全称循环冗余校验，本质上是把数据看作一个大整数，对它做模二除法，余数就是校验值。真正的复杂度在于"用什么多项式除""从什么余数开始""数据要不要按位反转""算完要不要再反转一次再异或"。这四个参数稍微变一下，算出来的CRC就完全不同。这也是现场两边都叫CRC16却对不上的根本原因。

工程里最常遇见的CRC16有三套：CRC16-MODBUS，多项式0x8005，初始值0xFFFF，输入输出都要反转，最终不异或；CRC16-CCITT-FALSE，多项式0x1021，初始值0xFFFF，不反转不异或；CRC16-XMODEM，和CCITT同一个多项式，但初始值是0x0000。此外还有CRC16-USB、CRC16-DNP，冷门归冷门，在特定行业里一样是标准。你光说"我用CRC16"，对面根本不知道你用哪套。

多项式本身也有两种写法。标准形是高位在左，比如0x8005；反转形把位序反过来，变成0xA001。很多查表法的表是基于反转多项式的，你拿0x8005去反向生成表格，又按反转后的算法去算，很可能绕晕。我的习惯是配置结构里把多项式、初值、反射标志、输出异或值都写清，然后用标准测试向量去验证实现，而不是凭记忆写。

2.2 CRC16-MODBUS为何是传感器领域的事实标准

做传感器通信，我个人首选CRC16-MODBUS。原因很简单：Modbus协议在工业控制和传感器采集领域太普及了，RS485、以太网网关、PLC、DTU这些设备几乎都认识Modbus的CRC16。选择这套参数意味着你至少能和一大票存量设备直接通信，不用做协议转换。

从工程角度看，CRC16-MODBUS的参数设计也很合理。初始值0xFFFF保证了从帧头到帧尾的完整覆盖，"输入反射"处理了对小端字节序最友好的位序。这里解释一下反射：CRC算法有两种位序理解方式，一种是最低位先处理（反射），一种是最高位先处理（非反射）。字节在内存里低位在前，反射模式直接按字节流顺序算，不需要先把字节按位反转，查表法实现起来特别顺。

0x8005这个多项式也经过长期实践验证。它检测所有奇数位错误、所有双位错误、所有长度不超过16的突发错误，概率上漏检率极低。对温湿度这种帧长不超过64字节的短报文来说，CRC16的检错能力已经足够。换算一下，CRC16对随机错误的漏检率是1/65536，对于一个每天上报17万包的传感器集群，理论上一整天可能漏掉约2.6个坏包。实际场景里数据错误往往不是均匀随机分布的，真正的风险远低于这个理论值。

2.3 CRC32的性能代价与启用条件

CRC32最常见的是IEEE 802.3标准的版本，多项式0x04C11DB7，初始值0xFFFFFFFF，输入输出反射，最终异或0xFFFFFFFF。以太网帧尾的FCS用的就是这一套，所以叫它"以太网CRC"一点没错。很多工程师想当然觉得："既然走以太网，CRC也用32吧，跟FCS一致多好。"这是典型的只看名字不看参数。IEEE 802.3的FCS虽然确实是CRC32，但那是MAC硬件在物理链路上算的，跟应用层软件算的CRC32根本不是一回事，参数相同纯属巧合，不代表更可靠。

CRC32比CRC16多了16位校验位，漏检率降到1/2^32。它检测所有长度不超过32的突发错误，对数据传输完整性、固件升级包校验、日志文件校验这种"一个比特都不能错"的场景非常合适。但它也实实在在增加了开销：查表法下表格是256个32位表项，占1KB内存；每次处理一个字节要做一次32位查表、两次移位、一次异或，计算量大约是CRC16的两倍。在STM32F103这种主频72MHz的单片机上，计算一个200字节的报文CRC32大约耗时几十微秒，这个量级对5秒上报一次的温湿度节点来说没有任何压力，所以性能并不是选CRC32的障碍。真正需要考虑的是协议兼容性和帧头开销——如果上下游设备和上位机软件已经统一用CRC16，换成CRC32反而增加联调成本。

2.4 一张表理清选型依据

选型的核心逻辑其实就一句话：在满足检错需求的前提下，优先选产业链里最通用的那套参数。CRC16-MODBUS是大多数情况下的安全牌；当帧长超过几百字节，或者传输的是不可重传的重要数据，再考虑CRC32。

3. STM32上两套代码实现：查表法与位运算法

3.1 位运算法：用时间换内存，理解原理必备

位运算法是最直观的CRC实现，适合新人理解算法本质，也适合内存极度受限的MCU。CRC16-MODBUS位运算的完整代码如下：

// 多项式 0x8005，反射后为 0xA001 // 初值 0xFFFF，输入输出均反射，结果不异或 static uint16_t crc16_modbus_bit(const uint8_t *data, uint32_t len) { uint16_t crc = 0xFFFF; while (len--) { crc ^= *data++; // 把当前字节和CRC低8位异或 for (int i = 0; i < 8; i++) { if (crc & 0x0001) { crc = (crc >> 1) ^ 0xA001; // LSB为1，右移后异或多项式 } else { crc >>= 1; } } } return crc; }

这里几个细节值得展开。初始值为什么设0xFFFF而不是0x0000？因为CRC算法在开头会先做一次异或，如果初值是0，那么所有前缀为零的数据段不会改变CRC状态，这会导致一个全零的数据块和一个被截掉若干前导零的数据块算出一样的CRC，降低检错能力。设成全1避免了这个问题。代码里用的0xA001是0x8005的反转形式，对应反射模式，所以每个字节低位先处理，这在内存小端序的MCU上最自然。

调用方要自行保证data指针有效、len不为0。因为CRC零长数据的返回值就是初始值加异或值，很多协议规定空数据包本身就不合法，所以我一般会在协议层直接拒绝len为0的帧。位运算版本每次处理8个比特，内部循环8次，如果数据量大了性能会明显吃力。对STM32F103跑72MHz来说，1毫秒能算大约200到500字节，这个性能对传感器帧够用，但绝不宽裕。

3.2 查表法：工程中真正常用的做法

工程上真正高频使用的是查表法。原理很简单：按字节处理时，8位输入和当前CRC低8位异或后的结果决定了"移8次后状态变化量"，这个变化量一共有256种可能，提前算好存成表格。计算一个字节只需要一次查表、两次移位两次异或，速度比位运算快八倍左右。

CRC16-MODBUS查表法的完整实现：

static uint16_t crc16_tab[256]; // 生成查表法用的表格 static void crc16_init_table(void) { for (uint16_t i = 0; i < 256; i++) { uint16_t crc = i; for (int j = 0; j < 8; j++) { if (crc & 0x0001) { crc = (crc >> 1) ^ 0xA001; } else { crc >>= 1; } } crc16_tab[i] = crc; } } static uint16_t crc16_modbus(const uint8_t *data, uint32_t len) { uint16_t crc = 0xFFFF; while (len--) { uint8_t idx = (crc ^ *data++) & 0xFF; crc = (crc >> 8) ^ crc16_tab[idx]; } return crc; }

表格初始化函数只在系统启动时调用一次即可，之后可以一直复用。也可以用静态常量数组直接把整个表写死在代码里，优点是省去启动时的初始化时间，缺点是代码段体积增加512字节。对绝大多数MCU来说都无所谓，我习惯用运行时初始化，反正启动阶段做一次，不到一毫秒。

查表法的正确性依赖表格生成算法和实际计算算法严格一致。如果你手上的表格是网上抄来的，务必先做一次标准验证。验证方法很简单：对字符串"123456789"计算CRC16-MODBUS，正确结果应该是0x4B37。这一条通不过，说明表格或算法参数有问题，排查半天没结果的CRC问题十有八九出在这里。

3.3 STM32硬件CRC外设的兼容性陷阱

STM32内部有个CRC外设，名字叫CRC，很多新手以为直接用硬件算CRC32就完事了。实际上STM32的硬件CRC外设默认多项式是0x04C11DB7，这确实是IEEE 802.3的CRC32多项式。但问题在于：STM32的老型号（F1、F4大部分）硬件模块默认不反转输入输出，不反射，初始值也是0xFFFFFFFF，最终结果没有输出异或。换句话说，它算出来的不是标准的"CRC-32/IEEE"，而是另一种变体。比如标准CRC32对"123456789"结果是0xCBF43926，STM32硬件外设算出来的却是另一个值，直接拿去和上位机的标准CRC32比对，必然不一致。

F4系列部分型号的CRC外设支持可编程多项式，H7系列可以配置初始值、多项式长度和反射标志，但配置项复杂，驱动代码反而比软件查表法难写。我的经验是：除非你在做数据流吞吐量极高的场景，比如每秒几十MB的传输，否则没必要在STM32上用硬件CRC。软件查表法在72MHz主频下每秒能算十几MB，对传感器通信绰绰有余，还避免了外设配置和标准不兼容的坑。

如果你确实想用硬件CRC外设，结论也很直接：去查对应型号参考手册的CRC寄存器配置，把RefIn、RefOut、Init、XorOut都设成和IEEE标准一致，然后用"123456789"做验证。验证不过，不要强行上线。

3.4 性能实测：一次校验到底要花多少时间

我在STM32F103C8T6上实际跑过一次对比，数据帧长度取64字节，主频72MHz，开O2优化。位运算法算完整帧约耗时62微秒，查表法约8微秒，差距接近8倍。对5秒上报周期来说，8微秒和62微秒都是毛毛雨。但如果节点设计成中断里实时计算CRC，查表法的8微秒优势会减少中断占用时间，对系统实时性更友好。

查表法的真正优势其实不在绝对速度，而在于开销可预测。查表法对每个字节的处理时间完全固定，没有任何分支依赖数据值，非常适合在实时性要求高的收发中断里使用。位运算虽然能省512字节的RAM表格，但每个字节内部循环是固定的，时间也不算不可预测，弱势只是在主频低的时候占用比例偏高。做传感器协议栈，我建议统一用查表法，省下来的CPU时间可以留给其他任务。

4. 以太网传感器帧结构里CRC的封装位置与字节序学问

4.1 一个典型的应用层帧格式

把CRC算出来只是第一步，怎么放进帧里同样有讲究。我们自研的以太网温湿度传感器应用层帧格式设计如下：

+--------+--------+--------+--------+---------+---------+---------+---------+ | 帧头 1 | 命令 1 | 长度 2 | 温度 2 | 湿度 2 | 状态 1 | CRC16 2 | 帧尾 2 | +--------+--------+--------+--------+---------+---------+---------+---------+

帧头固定为0xAA 0x55，命令字0x01代表周期上报。长度字段统计从温度到状态的总字节数。温度是int16_t，单位0.1℃；湿度是uint16_t，单位0.1%RH；状态字里放了电池电压告警、传感器自检结果等位标志。CRC16放在倒数第3、第4个字节，参与校验的范围从帧头到状态字结束，也就是除了CRC自身和帧尾之外的所有字节。帧尾固定为0x0D 0x0A，方便上位机用状态机切包。

这样设计有一个关键考虑：CRC一定要覆盖帧头。有些协议图省事只对数据域做CRC，帧头坏了靠帧尾的0x0D 0x0A去卡，但帧头错位可能导致整包数据解析错乱，而且帧尾两个字节出现在数据里的概率还不低。我把帧头、命令、长度全部纳入CRC计算范围，上位机收到包后可以先验CRC，验证通过再解析帧头，从根上避免了错位帧引发的一系列问题。

4.2 CRC字节到底该高字节在前还是低字节在前

CRC计算结果是16位无符号整数，但网线另一头的上位机可能是x86、ARM、MIPS，字节序各不相同。这个坑我在多个项目里见过：一个团队内部用STM32联调，小端脑放一切正常，换成x86服务器端才发现CRC放反了。所以必须在协议文档里明确规定：CRC低字节在前，还是高字节在前？

我的选择是低字节在前，也就是小端发送。原因有两个：第一，CRC16-MODBUS反射模式本身面向小端设计，算完用memcpy把uint16_t直接拷进发送缓冲区，在STM32上不需要任何字节交换；第二，很多协议解析工具默认把十六进制里的前两个字节当成第一个字段，低字节在前更符合主流抓包软件的显示习惯。如果对方是大端平台，接收时做一个简单的字节交换再比较，也很容易。

具体到实现里，假设帧缓冲区是uint8_t tx_buf[13]，CRC结果放在第9和第10字节：

uint16_t crc_val = crc16_modbus(tx_buf, 9); // 从帧头算到状态字，共9字节 tx_buf[9] = crc_val & 0xFF; // 低字节 tx_buf[10] = (crc_val >> 8) & 0xFF; // 高字节

这样写清晰直观，后续维护的人一眼就能看出字节序。最怕的是有人图省事这样写：

uint16_t *p = (uint16_t *)&tx_buf[9]; *p = crc_val;

指针强转在不同编译器、不同对齐策略下行为不一致，而且代码移植到其他平台时极容易踩坑。做通信协议，保持显式赋值比投机取巧安全得多。

4.3 增量CRC：长分片数据的处理思路

有些传感器不仅上报温湿度，还要上传日志、配置块、固件，数据可能长达几千字节。一个UDP包装不下时，通常要分片。分片传输时如果每一片都单独算CRC，那没问题；如果协议要求整体一个CRC，但数据又分成好几段到达，就需要增量CRC了。

增量CRC的思路是：CRC计算是状态相关的，算完一段数据后，把当前的crc变量保存下来，作为下一段的初始值继续算。查表法天然支持这一点，因为每次调用完，crc变量本身就是中间状态。实现上可以这样设计：

typedef struct { uint16_t crc; } crc16_ctx_t; static void crc16_modbus_init(crc16_ctx_t *ctx) { ctx->crc = 0xFFFF; } static void crc16_modbus_update(crc16_ctx_t *ctx, const uint8_t *data, uint32_t len) { uint16_t crc = ctx->crc; while (len--) { crc = (crc >> 8) ^ crc16_tab[(crc ^ *data++) & 0xFF]; } ctx->crc = crc; } static uint16_t crc16_modbus_final(crc16_ctx_t *ctx) { return ctx->crc; }

分片到达后，每段调用一次update，最后取final的结果。这个过程要注意一个前提：所有分片的顺序必须和数据流顺序一致，中途不能丢片、重排。UDP本身不保证顺序和交付，如果协议设计里没有分片序号和重传机制，增量CRC实际意义不大。所以我在自研协议里干脆不强推增量CRC，一律每包独立CRC，逻辑更省心。

5. 踩坑复盘：三起CRC事故的完整排查链路

5.1 事故一：同一包数据两端算出的CRC永远对不上

这是最经典的坑，也是开篇配电柜事件的真正原因。排查过程我完整还原一下：接收端报CRC错误后，我先用示波器确认PHY芯片的RX信号没有明显的毛刺，又用抓包工具把接收到的数据存下来，确认数据本身和发送端发出去的一模一样。问题不是出在传输链路，那就只能出在"算"上。

我把接收保存的那包数据和发送端发送的原始数据逐字节比对，完全一致，数据没问题。然后把同一段数据分别丢进两个CRC计算器里，一个用通用在线工具，一个用本地上位机的校验代码。结果上位机代码算出的值跟在线工具不一样。这时候终于明白，不是传输坏了，是两端对"CRC16"的理解不一致。去查上位机的代码，发现它用的是CRC16-CCITT的配置，发送端用的是CRC16-MODBUS。平时数据里没有0xFF字节时两个算法结果一样，一旦有0xFF就分道扬镳。

这个排查过程最值得记下来的教训是：当你觉得"数据明明没变，CRC却对不上"时，第一反应应该是检查两边的CRC参数是否一致，而不是怀疑传输链路。我浪费了将近半天在找干扰源上，最后发现问题出在一行配置上。现在我在做联调前，都会要求两边先用同一个标准向量"123456789"各自算一遍，对上了再联调。

5.2 事故二：温度出现负值时校验时好时坏

第二个坑出现在冬天室外测试。环境温度降到-5℃左右，上位机开始随机丢包。但丢包的规律让人摸不着头脑：同样是负数温度，有些帧能通过校验，有些不能。后来我把丢包的原始数据全部导出，比对温度字段的二进制值，发现通过校验和没通过校验的温度，byte-level表现完全一样，都是同一个负数。

问题出在解析代码里的类型转换。温度是int16_t，-5.0℃换算成内部值就是-50，内存表示是0xFFCE。发送端CRC是对原始字节0xCE 0xFF（低字节在前）算的，这没错。但接收端解析的时候，有的人用int16_t读温度，有的人用uint16_t读后再强制转换，还有的人直接从缓冲区里按大端组装。数据流里0xFFCE这个字节序在不同解析方式下会被理解成两种数值，但影响CRC计算的其实是原始字节，而不是解析后的数值。如果接收端在校验之前先做过一轮"预处理"——比如把温度字段先解析成int再转回字节去参与CRC计算——那就可能把0xFFCE的字节序搞反，校验自然失败。

排查思路是：把收到的原始字节直接丢进CRC校验函数，通过了就说明传输和计算没问题；如果原始字节通过了，解析以后却失败，那问题一定出在解析逻辑。我们最终的修复方案是：CRC永远对原始字节流计算，解析和校验是两个独立步骤，先验CRC再解析。这条规则后来写进了项目规范。

5.3 事故三：CRC查表法换了一个平台就翻车

第三个坑发生在把STM32的协议栈代码移植到另一个MCU平台时。算法代码几乎原样拷贝，表格生成函数也一样，但在新平台上跑起来，CRC结果总是不对。代码看起来完全一致，CPU也是小端，为什么结果不同？

后来仔细对比才发现，两个平台的编译器对uint16_t的类型定义不完全一致。一个平台上unsigned short就是16位，另一个平台上默认的short是16位但unsigned short在某些编译选项下被提升成了32位。我的表格生成函数里有个循环变量用的是unsigned int，在某些编译器行为下，crc >> 1执行的是32位右移，和16位的预期结果完全不同。这类问题在C语言里很隐蔽，因为类型提升规则和各种平台默认选项会悄悄改变行为。

解决方法是把所有CRC相关的变量和函数参数都显式声明为uint16_t和uint8_t，并且在新平台编译时打开-Wconversion之类的警告选项。代码里的数据宽度必须靠类型别名固定，而不是依赖平台默认类型。这个坑再一次说明了为什么做通信协议时，数据类型长度、字节序、结构体对齐这些细节必须写进编码规范。

6. 调CRC时最好先备上的验证工具和标准向量

6.1 用"123456789"验证实现

CRC领域有个著名的验证标准：对ASCII字符串"123456789"计算，不同参数族会得到固定的特征值，全球通用。我每次写完一段CRC代码，第一件事就是用这个字符串跑一遍，和预期结果比对。常用参数族的期望值如下：

这个表值得存到协议文档里。联调时双方先把各自实现对着这张表验证，能直接过滤掉一半以上的参数不匹配问题。如果计算结果对不上，不要急着改代码，先确认你手头的参考表本身用的是哪一套参数——网上很多CRC计算器默认配置各不相同，有的默认MODBUS，有的默认CCITT，看的时候要仔细。

6.2 和第三方计算器比对时先统一参数

在线CRC计算器虽然方便，但不同网站对"CRC16"的默认配置差异很大。有些网站让你手动选多项式、初值、反射和多字节序，有些则内置了别名列表。我在实际使用中吃过亏：用A网站算MODBUS格式拿到0x4B37，用B网站选CRC16默认格式却得到0xBB3D，一度以为是代码写错了。折腾半天后发现B网站默认用的是CRC-16/ARC，参数族跟MODBUS完全不是一回事。

所以和在线工具比对时，别只看网站名，要看它展示的参数配置页。确认多项式、初值、反射标志、输出异或值、结果字节序，和你的实现完全一致再比对。工具只是参考，标准向量才是最终依据。做得再顺一点，可以把"123456789"的特征值写进单元测试，每次代码改动后自动验证，CRC相关函数再也没出过回归问题。

最后再分享一个我自己的习惯：CRC选型、验证向量、字节序规则，一定要写进协议文档的第一章。很多联调事故翻来覆去就是同一个原因——文档里只写了"CRC16"，没写"CRC16-MODBUS，低字节在前，覆盖范围从帧头到状态字"。把这个细节写清楚，后来接手的同事能省下大量查错时间。我自己就是从"两个CRC16凑不出一个正确校验"的泥潭里爬出来的，写出来希望大家不用再爬一遍。