评论区有个兄弟说了一句话，我看了三遍。

“我做校园智慧洗衣机，一个学校3千到1万台，200个学校，几十万台设备，要求实时控制，我用Netty做了7年，很稳定。现在做工业园区智慧管理，用MQTT，每个网关连接100个设备左右，做了一年半了。”

这短短两段话，把工业物联网协议选型最核心的矛盾说透了。

同样是物联网项目，为什么第一个选了Netty，第二个选了MQTT？为什么两个都能跑？今天我不站队，把Netty和MQTT的底层逻辑拆开，说清楚什么场景该用什么。

Netty是什么，为什么适合大规模设备接入？

Netty本质是一个高性能的网络通信框架，基于Java NIO的多路复用机制构建。它采用事件驱动的异步非阻塞模型，不需要为每一个连接分配一个线程，仅通过少量线程就能管理海量并发连接-18。

这意味着什么？假设你有10万台洗衣机需要同时保持在线，如果用传统的“一个连接一个线程”模型，需要10万个线程，操作系统根本扛不住。而Netty用事件驱动模型，可能只需要几十个线程就能管理这10万个连接。

Netty还内置了连接保活检测、断线重连、报文编解码、异常处理机制，这些在物联网场景里非常关键。终端设备部署在户外、网络波动频繁，需要服务端具备精准的连接状态检测和异常连接清理能力-18。

那位兄弟用Netty做几十万台洗衣机的实时控制，稳定跑了7年，这个数据本身就是最好的背书。

但Netty有一个前提条件：设备端需要按照你自定义的TCP协议来通信。

这意味着设备端的固件程序是你控制的。校园洗衣机项目里，洗衣机厂商愿意配合你改固件、适配你的协议——这在大规模设备场景里是可以做到的。但如果你的设备是西门子PLC、是施耐德变频器、是三菱机器人，你不可能让西门子给你改固件。

MQTT是什么，为什么适合工业园区？

MQTT是一个标准的发布/订阅消息协议，基于TCP/IP的极轻量级传输，专门为网络带宽有限的远程连接场景设计-27。

MQTT的核心优势在于标准化。它是一个OASIS标准协议，任何支持MQTT的设备都能接入，不需要自定义协议。工业园区的设备来自不同厂家，你不可能要求所有厂家都适配你的私有协议。

一个真实的大规模园区案例：某全球楼宇自动化龙头企业用MQTT方案，在单个园区部署了温控设备、PLC、照明控制器、边缘网关等数百台终端，人流峰值时段全设备消息吞吐量达80万到100万条/秒-31。这个数据说明MQTT在规模上并不弱。

但MQTT的致命弱点是什么？

不是为确定性或硬实时通信设计的。它可以通过QoS设置支持可靠投递，但不能保证可预测的时序-3。

一篇2026年发表的学术论文用真实测试台做了对比：在远程云部署场景下，WebSocket-S7桥接方案的平均往返延迟是87ms，MQTT的往返延迟是133ms，Modbus是194ms-2。

133ms是什么概念？如果一个安全联锁系统要求“检测到危险信号后50ms内切断电源”，用MQTT根本做不到。因为MQTT的消息要走Broker，Broker本身可能有延迟、有队列、有拥塞。

这就是那位兄弟在校园洗衣机项目用Netty、在工业园区用MQTT的原因：

洗衣机要求“用户扫码支付后立即启动”，实时控制要求高，用Netty的TCP长连接直接下发指令，延迟可以控制在毫秒级

工业园区的设备监控、环境数据采集，对实时性要求不高，用MQTT的标准化接入更省事

那到底该怎么选？我用一张表说清楚。

维度 Netty（自定义TCP） MQTT 实时性 毫秒级，可控制 几十到几百毫秒，取决于网络和Broker 设备接入数量 理论无上限，取决于服务器资源 百万级（需要高性能Broker） 设备端要求 需适配你的自定义协议 支持标准MQTT协议即可 安全性 需自行实现 支持TLS/SSL加密 开发复杂度 高（协议设计、连接管理、心跳、重连全部自己写） 低（用现成的Broker和客户端库） 适用场景 实时控制、大规模自有设备、固件可控 数据采集、设备监控、多品牌设备接入 实际案例 校园洗衣机（几十万台，7年稳定） 工业园区（每网关100设备，1.5年）-31 说点得罪人的真话。

行业里有一种声音说“MQTT是工业物联网的唯一选择”。这是不对的。

MQTT的优势在于标准化——多品牌设备、跨厂家、跨平台。但如果你的设备固件是你自己控制的，如果你的项目对实时控制有硬性要求，自定义TCP + Netty仍然是最好的选择。

另一种声音说“Netty比MQTT性能高”。这也不全对。

Netty的性能优势只体现在“可控的协议”和“可控的设备”上。一旦设备来自多个厂家、协议五花八门，Netty就变成了一个“通用网络框架”——你的开发工作量会比用MQTT大得多。

我的建议：

场景一：自有设备、固件可控、实时控制要求高 → Netty + 自定义TCP。 那位兄弟的校园洗衣机项目就是典型案例，几十万台设备、7年稳定运行。

场景二：多品牌设备接入、以数据采集为主 → MQTT。 工业园区的项目就是这种场景，设备来自不同厂家，用MQTT标准化接入最省事。

场景三：既需要实时控制又需要数据采集 → 混合架构。 控制指令走Netty/TCP直连，数据采集走MQTT上传。两种协议各管各的，不要强求统一。

没有最好的协议，只有最合适的场景。

做技术选型的时候，先问自己三个问题：设备固件我能不能控制？实时性要求是多少毫秒？设备数量级是几千还是几十万？答案出来了，选型就清楚了。

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

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

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