很多工程争议源于一个误解：以为Modbus TCP和Modbus RTU是"两代协议"。其实不是。两者共享完全相同的应用层——同样的功能码（01/02/03/04/05/06/15/16）、同样的寄存器模型（4xxxx保持寄存器、3xxxx输入寄存器、0xxxx线圈）、同样的数据编码。区别只在报文怎么打包、跑在什么物理网络上。
RTU跑在RS-485串行总线上，帧格式是"从站地址 + PDU + CRC16校验"，整条总线同一时刻只能有一方说话；TCP跑在以太网上，帧格式换成"MBAP头（事务ID/协议ID/长度/单元标识）+ PDU"，由IP网络负责路由与纠错，一个设备可以同时应答多个客户端。在上一篇通信协议全景指南：Modbus/BACnet/MQTT/OPC UA对比与选型决策树里我们把Modbus归为"设备级采集协议"，本文往下钻一层：同一个Modbus，两条路线，工程现场到底怎么选。
RTU的核心资产是RS-485总线：一对双绞线，半双工，理论上挂32个标准负载（用1/4单位负载收发器可扩展到128个），最长传输距离约1200米（低波特率下）。传感器、电量表、变频器、压差变送器——楼宇里绝大多数末端设备天生带RS-485口，这是RTU至今统治设备级的原因。
但RS-485的边界同样清晰：
帧层面的细节——CRC怎么算、地址1~247怎么排、异常码怎么看——在Modbus/BACnet协议详解：帧格式、寻址与组网方式的工程要点里已经拆过，这里不再重复。
Modbus TCP把PDU原样塞进TCP包，默认端口502，校验交给TCP层，因此报文里不再有CRC。它带来的三个结构性优势：
多客户端并发。一台TCP设备可以同时被BMS、能耗平台、第三方运维系统同时读取，各连各的TCP会话，互不争抢。RTU总线上这是不可能的。
带宽与距离脱钩。千兆以太网加光纤，跨楼栋、跨园区传输没有1200米的概念，带宽也不再是瓶颈——一次读125个保持寄存器（功能码03的上限）只是毫秒级。
与IT设施复用。楼里有综合布线、有交换机、有VLAN，Modbus TCP直接"搭车"，布线成本显著低于专门铺485。
代价也有：IP网络引入了新的故障域（交换机宕机、VLAN配错、IP冲突），且不少老式TCP设备对并发连接数、半开连接超时处理粗糙，接入设计要比485更讲究。
现场选型不需要背参数，回答五个问题基本就有答案：
| 问题 | 偏向RTU | 偏向TCP |
|---|---|---|
| 1. 设备在哪？ | 同一管井、同一配电房，30米内集中 | 跨楼层、跨楼栋、园区级分散 |
| 2. 距离多远？ | ≤800米（留裕量） | 超距或需光纤隔离强电干扰 |
| 3. 谁要数据？ | 单一系统读取 | BMS+能耗平台+第三方多方并发 |
| 4. 末端设备有什么口？ | 只有RS-485（大多数表计传感器） | 原生RJ45（智能电表、新型控制器） |
| 5. 改造还是新建？ | 存量项目，沿用原485布线 | 新建项目，综合布线一步到位 |
注意一个常被忽略的事实：同一厂家同型号设备，RTU和TCP版本通常保持完全一致的寄存器地图。这意味着路线选择可以分阶段：先用RTU跑起来，后期加串口服务器转成TCP上行，上位机软件几乎不用改。
真实项目里九成是混用，标准画法是三层：
末端层（RTU）。压差、温湿度、电量表等末端设备按物理分区挂在RS-485总线上，每条总线控制在合理长度与负载内。选什么信号输出、走哪类总线，可参考传感器选型大全：按建筑场景选型号的一站式指南中"输出信号与通信协议"一节的决策逻辑。
汇聚层。两种做法：预算紧就用多口串口服务器把若干条485透传成TCP；更稳的做法是用原生支持双栈的网关——比如同时支持Modbus RTU/TCP、BACnet/IP、OPC UA与MQTT四种协议直连的能耗网关，向下轮询多条RS-485总线，向上以Modbus TCP（或直接MQTT上云）提供数据，顺带解决多主站并发与协议翻译问题。
主站层（TCP）。BMS或能耗平台统一走TCP/IP取数，调度侧常见ECC200网络控制器：BACnet/IP与Modbus双协议楼宇自控主控，把Modbus侧的电表、冷量表数据与BACnet侧的空调机组状态放在同一个控制逻辑里联动。
这套"485到底、TCP到顶"的结构，既能吃满RS-485的低成本布线红利，又能在主干上享受多客户端并发与IT复用，是能耗监测与楼宇自控项目里性价比最高的折中。
1. 把Unit ID当成IP。通过串口服务器访问一条485总线时，一个TCP连接后面挂着几十个从站，上位机驱动必须按"Unit ID = 一条虚拟RTU总线上的站号"建模，而不是给每个站配一个IP。配错的表现是：单点测试全通，一跑整线轮询就大面积超时。
2. 多主站同时透传轮询。两台服务器通过同一个串口服务器各查各的，485总线立刻冲突。解法：要么网关内置仲裁（单主站轮询、多客户端读缓存），要么划清地盘——一个端口一条总线一个主站。
3. 超时参数一刀切。RTU从站响应超时与波特率强相关（9600bps下含帧传输动辄上百毫秒），而TCP会话超时以秒计。混用系统里把RTU那套毫秒级参数搬到TCP网关后面，或者反过来，都会引发重试雪崩。
4. 以为广播还能用。RTU的0号从站广播写（比如同步时钟）在TCP上没有统一语义，很多TCP设备直接忽略。批量对时的正确姿势是逐站单播循环，或确认设备明确支持广播。
5. 忽略单帧寄存器上限。功能码03一次最多读125个寄存器，但很多网关/串口服务器还叠加了自己更小的分帧限制。读到"中途断包、CRC错或长度错"，先查单次请求长度，再查线缆。
以一个配电房典型配置为例：32块导轨电表挂一条RS-485，波特率9600，每块表读8个保持寄存器。9600bps、8N1编码下每个字节约11位，单次"读8寄存器"请求帧8字节、响应帧约21字节，加总线翻转等待（turnaround，典型20~50毫秒），单点耗时约60~90毫秒：
| 波特率 | 单点耗时（估） | 32点轮询周期 | 适用判断 |
|---|---|---|---|
| 9600 bps | 约60~90 ms | 约2~3 秒 | 分钟级能耗采集完全够用 |
| 19200 bps | 约40~60 ms | 约1.5~2 秒 | 点位翻倍时优先提波特率 |
| 115200 bps | 约25~45 ms | 约1~1.5 秒 | 短距离高速场景，线缆质量要求高 |
结论：能耗监测的秒级~分钟级需求，RTU轮询绰绰有余；真正逼你上TCP的，从来是距离、分散度、多主站并发这三件事，而不是速度。
Modbus TCP和RTU不是新旧替代关系，而是同一份寄存器地图在两段不同网络上的跑法：485负责把几十米范围内的末端设备低成本串起来，TCP负责把数据干净、并发、远距离地送进主站。选型的成熟标志，是看到项目图纸时脑子里自动出现三层架构，并立刻能指出每条总线的负载、波特率和汇聚点。下一篇我们将进入Q4技术干货系列的多协议网关选型话题，拆解异构系统整合的工程细节，敬请关注。
延伸阅读：通信协议全景指南：Modbus/BACnet/MQTT/OPC UA对比与选型决策树 · Modbus/BACnet协议详解：帧格式、寻址与组网方式 · 多协议能耗网关（RTU/TCP双栈汇聚） · ECC200网络控制器（TCP侧主站调度） · 传感器选型大全
