MQTT这几年被捧得很高。很多方案里，不管什么场景，先上一个MQTT Broker再说。

但我用了3年MQTT之后发现——MQTT在工业现场有4个场景是真的不适合，硬用只会给自己找麻烦。

场景一：安全联锁回路。

一个化工项目，安全联锁系统需要在检测到压力超标后50ms内切断进料阀。

有人提议“用MQTT下发切断指令，快得很”。

这是要命的错误。

MQTT的消息从发布者到Broker再到订阅者，中间经过了至少两跳。Broker本身可能因为消息积压产生延迟。而且MQTT的QoS机制——QoS 0是“尽力投递”，不保证送达；QoS 1是“至少送达一次”，可能重复；QoS 2是“恰好送达一次”，但延迟最高-41。

安全联锁系统里，指令必须确定性送达，必须在规定时间内确定执行。MQTT做不到这一点。

安全联锁用什么？ 硬件安全继电器、安全PLC（通过专用安全总线通讯）。不要用MQTT碰安全回路。

场景二：高速运动控制。

一个包装机项目，伺服电机需要每1ms同步一次位置指令。

有人建议用MQTT下发位置指令——完全行不通。

MQTT是发布/订阅模型，消息先到Broker再到订阅者。这个过程中，消息可能被排队、可能被重发、可能延迟。对于1ms级的同步控制，MQTT的延迟是“不可预测”的。

而且MQTT的消息投递延迟取决于Broker性能、网络拥塞和QoS等级-。一个高性能的Broker在理想网络下延迟是几毫秒，但在工业现场的网络环境下，延迟可能到几十毫秒甚至几百毫秒。

运动控制用什么？ EtherCAT、PROFINET IRT、CANopen——这些协议的设计目标就是确定性的实时通信，不是MQTT能替代的。

场景三：大量模拟量高频采集。

一个振动监测项目，20个振动传感器，每个每秒采集1000个数据点。

有人建议用MQTT把每个数据点都发到云端。

算一下数据量： 20个传感器 × 1000个数据点/秒 = 每秒2万个数据点。每个数据点打包成JSON约100字节，每秒2MB的数据量。一天下来172GB。

而且这些数据点在云端还要做FFT频谱分析——数据传上去再分析，延迟大、带宽成本高。

正确的做法是： 振动数据在边缘侧做预处理（FFT变换、特征提取），只把“特征值”和“异常标志”上传到云端。原始数据存在本地，需要的时候再调取。

我们做过对比：同样20个振动传感器，全量上传MQTT每秒2MB，边缘侧预处理后上传每秒不到20KB。带宽降低了99%。

场景四：跨网段的实时指令下发。

一个厂区，OT网络和IT网络是隔离的。有人建议“用MQTT穿透两个网络，让IT系统直接控制OT设备”。

这是安全上的大忌。

OT网络里的设备（PLC、伺服、变频器）对实时性和确定性要求极高。IT网络里的各种流量——广播包、组播包、大文件下载、视频流——会干扰工业通信。把两个网络打通，等于让IT网络的“不可预测性”入侵OT网络的“确定性”。

正确的做法是： OT网络和IT网络物理隔离。数据从OT流向IT通过边缘网关，网关在OT侧只做“只读采集”，在IT侧做数据转发。数据单向流动，不允许反向控制。

EdgeLiteGateway就是按这个思路设计的——采集端接OT网络，转发端接IT网络，两个网络物理隔离。

那MQTT到底能用在哪？

不是不能用了，是要用对地方：

数据采集和监控： 非实时性的传感器数据上传，用MQTT最省事

边缘到云端的数据传输： 网关采集完数据后通过MQTT推送到云平台

跨地域的设备管理： 分布在多地的设备通过MQTT统一管理

事件通知和告警： 非安全相关的告警信息推送

一句话总结：MQTT管“信息”，不管“控制”。

安全控制用硬件安全系统，运动控制用实时以太网，数据采集用MQTT，各司其职。

平时我也写写代码，维护两个开源项目：

ProtoForge（工业协议仿真平台，28种协议，130+设备模板）： GitHub：suoten/ProtoForge Gitee：suoten/ProtoForge

EdgeLiteGateway（AI物联网关，13种协议采集，边缘AI推理）： GitHub：suoten/EdgeLiteGateway Gitee：suoten/EdgeLiteGateway