Modbus 数据采集是工业现场最普遍的需求，而 Modbus 本身也是最容易被低估的协议。很多人觉得它简单——一个功能码加一段数据，读回来解析就行。实际做过项目就知道，十个 Modbus 数据采集项目有九个出过问题，而且问题高度集中。
我把这些年踩过的坑归了类：寄存器地址差 1、32 位数据字节序反了、异常码不看就盲目重试。这三类占了八成故障，剩下的两成是超时、串口参数、从站地址冲突。
下面逐条拆。
一、寄存器地址差 1：Modbus 数据采集里 40001 到底该填 0 还是 1
这是 Modbus 数据采集的第一大坑，也是最容易让人怀疑人生的一个。
设备手册上写着「保持寄存器 40001」，你把它填进 Modbus 数据采集程序，读回来全是 0 或者直接异常。换成 40000 也不行，填 1 才正常。
原因在于 Modbus 有两套地址体系，设备厂商混着用：
| 地址类型 | 编号范围 | 协议里的实际偏移 | 说明 |
|---|---|---|---|
| 线圈 Coil | 00001 - 09999 | 0 - 9998 | 可读可写，1 bit |
| 离散输入 Discrete Input | 10001 - 19999 | 0 - 9998 | 只读，1 bit |
| 输入寄存器 Input Register | 30001 - 39999 | 0 - 9998 | 只读，16 bit |
| 保持寄存器 Holding Register | 40001 - 49999 | 0 - 9998 | 可读可写，16 bit |
关键在于：协议报文里传的是偏移量，不是编号。40001 对应报文里的 0，40002 对应 1，依此类推。
所以看到手册写 40001，采集程序里应该填 0。但很多国产设备手册直接写「寄存器地址：1」，这时候填 1 才对——因为它给的已经是偏移量了。
怎么快速判断：先按手册的原始数字读一次，读不到就减 1 再试。如果两个都能读到但数值差一位，说明这个设备的地址表是连续的，需要用实际物理量验证——比如读温度寄存器，用手捂一下传感器看数值变不变，变的是对的。
还有一个更隐蔽的坑：有些设备的地址表里，40001 和 40002 是两个独立的 16 位寄存器，但有些设备把 40001+40002 拼成一个 32 位浮点数。手册如果没写清楚，你会读出两个看起来都正常的整数，但拼起来是天文数字。
二、字节序：32 位数据反了，读数差几万倍
Modbus 协议规定寄存器内部是大端字节序（高字节在前），但只规定了 16 位。当一个 32 位数据要占两个寄存器时，先放高 16 位还是低 16 位，协议没规定，厂商自由发挥。
于是就有了四种组合：
| 组合 | 字节顺序 | 常见叫法 | 典型厂商 |
|---|---|---|---|
| ABCD | 大端，高字在前 | Big Endian | 多数欧美设备 |
| CDAB | 大端字节，低字在前 | Big Endian with byte swap | 部分电力仪表 |
| BADC | 小端字节，高字在前 | Little Endian with word swap | 少数日系设备 |
| DCBA | 小端，低字在前 | Little Endian | 部分国产 PLC |
举个具体例子。真实值 1234.5678 的 IEEE754 单精度浮点是 0x449A522B。四个寄存器读回来的值可能是：
- ABCD：
0x449A、0x522B→ 解析出 1234.5678 ✅ - CDAB：
0x522B、0x449A→ 按 ABCD 解析出0x522B449A，约 1.15e11，差了八个数量级 - BADC：
0x9A44、0x2B52→ 解析出完全离谱的数 - DCBA：
0x2B52、0x9A44→ 同上
怎么确定设备用哪种：找一个你知道大概范围的物理量，比如室温应该在 15-35 度之间。四种组合都试一遍，只有一个会落在这个区间。不要靠猜，也不要相信手册——手册写错的概率不低。
更稳的做法是：在采集程序里给每个点位配一个 byteOrder 字段，配置化而不是写死。后期换设备不用改代码。
三、功能码选错：03 和 04 不是随便挑
读寄存器有两个功能码，很多人以为随便用哪个都行，实际不行。
- 03（Read Holding Registers）：读保持寄存器，地址区 4xxxx
- 04（Read Input Registers）：读输入寄存器，地址区 3xxxx
区别在于语义：保持寄存器是可读可写的，掉电保持；输入寄存器是只读的，通常是实时采集值。有些设备两者映射同一块内存，用 03 和 04 读到一样的数据；有些设备严格区分，用错功能码直接返回异常码 0x02（非法数据地址）。
写寄存器也有两个：
- 06（Write Single Register）：写单个 16 位寄存器
- 16 / 0x10（Write Multiple Registers）：写多个寄存器，也能写单个
建议：写单个用 06，写多个用 16。有些老设备不支持 16，只认 06；也有些不支持 06，只认 16。第一次接入时两个都测一遍，记在设备档案里。
还有个容易被忽略的点：写寄存器后要回读验证。有些设备的写操作是「接受但忽略」，返回正常响应，实际值没变——可能是写保护跳线没拔，也可能是这个寄存器在当前工作模式下不可写。不回读就以为成功了，排查时会绕很久。
四、异常码：设备在明确告诉你哪里错了
Modbus 的异常响应格式很清晰：功能码最高位置 1，后面跟一个异常码。比如请求功能码 03，异常响应就是 0x83 + 异常码。
| 异常码 | 含义 | 实际原因 |
|---|---|---|
| 0x01 | 非法功能 | 设备不支持这个功能码 |
| 0x02 | 非法数据地址 | 地址超范围，或地址差 1 |
| 0x03 | 非法数据值 | 写入的值超出允许范围 |
| 0x04 | 从站设备故障 | 设备内部异常，可能需要重启 |
| 0x05 | 确认 | 设备正在处理长任务，需要轮询 |
| 0x06 | 从站设备忙 | 设备处理不过来，降低频率 |
| 0x08 | 存储奇偶性差错 | 设备存储区异常 |
| 0x0A | 网关路径不可用 | 网关后面的设备没响应 |
| 0x0B | 网关目标设备无响应 | 从站掉线或地址错 |
看到 0x02，别急着重试，先检查地址。看到 0x06，说明你的采集频率太高了，把轮询间隔从 1 秒改成 5 秒可能就正常了。看到 0x0B，说明问题在下游设备，不是网关。
反模式：把异常当超时处理，直接重试三次。重试对 0x02 和 0x03 完全无效，只会浪费总线时间，还可能把设备惹毛。
五、RTU 和 TCP 的工程差异
很多教程说「RTU 是串口，TCP 是网口，其他一样」，实际差异不小。
| 维度 | Modbus RTU | Modbus TCP |
|---|---|---|
| 传输层 | RS485 / RS232 | TCP 502 端口 |
| 校验 | CRC16 | 无（靠 TCP 保证） |
| 从站标识 | 1 字节地址（1-247） | MBAP 头里的 Unit ID |
| 帧边界 | 靠 3.5 字符静默间隔 | 靠 TCP 分段 |
| 并发 | 半双工，一主多从串行 | 多连接并发 |
| 典型延迟 | 10-100ms（取决于波特率） | 1-10ms（局域网） |
RTU 最容易被忽略的是 3.5 字符间隔。协议规定帧之间至少静默 3.5 个字符时间，波特率 9600 时大约是 4ms。如果你的程序连续快速发两帧，设备会把它们当成一帧，解析出错。用现成的库一般没问题，自己拼报文要特别注意。
TCP 的 Unit ID 是个坑。TCP 报文里有 MBAP 头，包含 Unit ID 字段。直连设备时这个字段通常填 1 或者 255；通过网关时，它表示网关后面的 RTU 从站地址。填错了网关会返回 0x0B。
另一个常见问题：Modbus TCP 设备通常只支持 1-4 个并发连接。多个采集程序同时连，后面的会被拒绝。做冗余采集时要在架构上避免——让一个采集器统一收，再分发，不要多个程序各自连设备。
六、批量读还是单点读：这是个性能问题
Modbus 一次最多读 125 个寄存器（功能码 03/04）或 2000 个线圈（01/02）。但实际不会读满，因为：
- RTU 在 9600 波特率下，读 125 个寄存器要 260 毫秒左右，加上从站处理时间，接近半秒
- 很多设备一次只支持读 10-20 个寄存器，超了返回异常
- 寄存器地址不连续时，必须分多次读
优化原则：把地址连续的寄存器合并成一次读，中间的空洞也一起读回来丢弃，比多次请求快得多。比如要读 40001-40005 和 40008-40010，不如一次读 40001-40010（10 个），拿到后丢弃 40006、40007。
但如果两个点位相距很远（比如 40001 和 40100），强行合并会读到大量无用数据，反而慢。经验值：间隔在 20 个寄存器以内就合并，超过就分开读。
还有一个必须注意的：从站的响应能力。便宜的温控表可能一次只能处理 8 个寄存器，你要读 20 个，它会返回 0x04 或者干脆不响应。这时候只能拆成 3 次。
七、超时和重试：参数设错比不设更糟
RTU 的响应超时经验值：
- 波特率 9600，超时设 300-500ms
- 波特率 19200，超时设 200-300ms
- 波特率 115200，超时设 100-150ms
设太短，设备还没处理完就判超时，误判率高；设太长，一台设备掉线会拖慢整条总线。
重试策略：最多重试 2 次，且只在超时和 0x06（设备忙）时重试。地址类异常（0x02）和功能码类异常（0x01）重试一万次也不会成功。
更重要的：连续失败要熔断。一台设备连续 10 次超时，就把它标记为离线，暂停采集 5 分钟再试。否则它会一直占用总线时间，把其他正常设备也拖垮。这在 RTU 总线上尤其明显——半双工，一个从站不响应，主机要等满超时才轮到下一个。
接入前的检查清单
把这七条做成一个 checklist，每次接新设备过一遍，能省掉大部分返工：
- 地址偏移量确认：手册给的编号减 1，还是本来就是偏移量
- 字节序确认：四种组合试一遍，用已知量验证
- 功能码确认：03 还是 04，06 还是 16
- 单次读取上限：一次最多能读几个寄存器
- 超时和重试：按波特率定，只在超时和设备忙时重试
- 熔断阈值：连续失败几次判定离线
- 写后回读：写寄存器必须验证实际生效
Modbus 的问题从来不在协议本身，都在这些工程细节里。协议文档只有几十页，但把这些细节搞清楚，通常要经历几个项目。希望这篇能帮你少走一两个。