评论区“林间隐居宁静致远”的项目，有一个细节值得深挖。

他的校园洗衣机项目，用的是Netty + 自定义TCP协议。也就是说——协议是他自己设计的。

“自己写协议”这个事，在工控圈里有争议。

有人说：“有标准协议为什么不用？Modbus、MQTT、OPC UA都是现成的，非要自己造轮子。”

有人说：“标准协议满足不了我的需求，我就自己写。”

到底该不该自己写协议？

先说一个真实案例。

一个做充电桩的公司，早期用的是MQTT。每个充电桩通过MQTT上报状态、接收控制指令。

用了一段时间发现几个问题：

第一，实时控制延迟大。用户扫码充电，从扫码到充电桩启动，中间要经过“APP→云端→MQTT Broker→充电桩”四个环节，延迟有时候超过2秒。

第二，MQTT的QoS机制增加了开销。每条控制指令都要走QoS 1，充电桩和Broker之间的握手次数是数据上报的好几倍。

第三，充电桩的固件是他们自己写的，完全可以自定义协议。

后来他们改成自定义TCP协议。 充电桩和服务器直接建立TCP长连接，控制指令直接下发，延迟从2秒降到了200毫秒以内。

什么时候适合自己写协议？

条件一：设备端固件可控。

如果设备是你自己开发的，固件是你自己写的，你可以自定义协议。如果设备是第三方厂家的，固件改不了，只能用标准协议。

条件二：标准协议满足不了需求。

比如超低延迟、超低功耗、特殊的数据格式——标准协议在这些方面有局限。

条件三：有网络编程能力。

自定义协议意味着你要自己处理TCP连接的建立、维持、断开、重连、粘包、拆包、心跳、超时、重传。这些工作，Netty帮你处理了一部分，但协议的设计和业务逻辑还是得自己写。

那什么时候不该自己写协议？

场景一：多品牌设备接入。

设备来自西门子、三菱、汇川、施耐德——你不可能让每个厂家都按你的协议改固件。这种情况下，只能用标准协议（Modbus、OPC UA、MQTT）。

场景二：团队没有网络编程经验。

自定义协议看起来简单——“就是发JSON嘛”。但真正做起来，要考虑粘包怎么处理、心跳怎么设计、断线怎么重连、并发怎么控制。没有经验的话，坑很多。

场景三：项目周期短。

自定义协议需要设计、开发、测试、调试。标准协议拿来就能用。如果项目周期紧张，用标准协议更稳妥。

我的建议：能用标准协议就用标准协议。

标准协议经过了大量项目的验证，稳定性有保障。而且标准协议的生态好——调试工具、客户端库、社区支持都很完善。

但如果满足这三个条件——设备固件可控、标准协议满足不了需求、团队有网络编程能力——自定义协议是更好的选择。

那位兄弟的校园洗衣机项目就是典型案例——设备是自己做的、实时控制有硬性要求、团队有Netty开发能力。三个条件都满足，自定义协议跑7年稳定。

最后说一个趋势。

工业物联网正在从“私有协议”向“标准协议”演进。以前每个厂家都有自己的协议，现在越来越多的设备支持Modbus、OPC UA、MQTT。

但“标准协议统一天下”不现实。因为不同场景的需求差异太大了——有的要实时、有的要省电、有的要安全。标准协议不可能覆盖所有场景。

未来是“标准协议为主，自定义协议为辅”的格局。

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

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

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