基于MQTTnet的C# MQTT服务器端实现与自建Broker实战

说真的，做C#这么多年，最让我头疼的从来不是业务逻辑怎么写，而是设备之间、系统之间那点事怎么串。尤其是搞上位机、搞物联网、搞硬件对接的兄弟，一定会遇到这种情况：摄像头识别结果要往后台推、PLC的数据要实时上报、工位上的传感器状态要同步到多个看板……以前大家的做法要么是写TCP长连接自定义协议，要么是轮询数据库，前者开发量大还难维护，后者延迟高得没法看。直到我用MQTT把这条链路打通，才发现原来设备接入可以这么清爽。而当我进一步把开源的C# MQTT服务器端源码跑起来、改起来之后，才真正体会到什么叫“摆脱限制”。

这篇文章要聊的，就是怎么基于开源免费的C# MQTT服务器端实现，搭一个属于你自己的消息中间件。它不是某个只能在特定平台跑的商业产品，而是能嵌进你自己的服务、能改源码、能按业务随意扩展的Broker层。不管你是想给停车场项目对接车牌识别相机，还是想给工厂设备做数据采集，又或者只是想在手边有个不依赖公网的消息总线，这篇文章都值得你花十分钟看完。

1. 自建 MQTT 服务器：为什么这件事值得做

1.1 先别急着写代码：什么时候需要自己的 Broker

我知道很多人第一反应是：网上有那么多免费的MQTT服务器，用现成的不行吗？比如常见的公共Broker，或者去云平台开一个MQTT实例。能用，分场景。如果你是做技术验证、写个Demo，那公共Broker完全够用，打开就能连，省事。但我劝你，只要项目进入真实部署阶段，就一定要认真评估自建方案。

原因特别简单，公共Broker要么有连接数限制，要么有流量限制，要么就是消息存储时间短、你无法控制数据安全。更关键的是，一旦你的设备量上来，或者业务逻辑需要你深度定制，比如在服务端直接做设备鉴权、按产品线隔离Topic、把收到的数据直接写进数据库，公共Broker根本满足不了这些需求。这时候，把MQTT服务器端源代码拿过来自己部署、自己改，就成了唯一靠谱的选择。

还有一类典型场景是纯内网环境。很多工厂、园区、医院的数据根本不允许出内网，但又需要一套灵活的消息机制来串联各个子系统。自建Broker意味着数据完全在自己手里，网络层面也完全可控，没有任何第三方依赖。说实话，光“可控”这两个字，就值回所有折腾成本了。

1.2 MQTT Broker 选型横向对比：为什么 C# 项目值得选 MQTTnet

真要选开源的MQTT Broker，市面上可选项挺多的，比如Mosquitto、EMQX、HiveMQ，还有C#生态里最出名的MQTTnet。我做了一张对比表，方便你看清楚各自的定位：

可能有人会问，EMQX和Mosquitto不是很成熟吗？为什么偏要选一个C#的库？我的理由很直接：你是C#开发者，MQTTnet能让你用最熟悉的语言去理解、修改消息中间件的行为，而不是去啃C或者Erlang的源码。项目里所有代码都是C#，意味着你整个团队的学习成本和维护成本都会低很多。

另外一个很重要的因素是可嵌入性。MQTTnet不是一个独立进程，它是一个类库。这意味着你可以把Broker直接跑在你的上位机进程里，也可以在同一个解决方案里拆出一个独立的服务项目来部署。这种灵活度，是Mosquitto这种独立进程给不了的。你要是为了让Broker配合自己的业务逻辑，还得再写一堆外部程序去调它，太难受了。

1.3 自建方案能带来哪些实实在在的好处

自建Broker第一个显而易见的好处就是零成本。MQTTnet是MIT协议的，商用、内用都不需要付费，没有授权数量限制。你可以开开心心地把它部署在任意厂商的Windows服务器上，也可以部署在Linux容器里，甚至直接塞进工控机，随意折腾。

第二个好处是深度可控。消息怎么路由、哪些客户端能连、Topic该怎么命名、每条消息要不要落库……这些逻辑都能直接在服务端代码里写死，而不是依赖外部Broker提供的有限配置项。举个例子，我在做一个设备接入的项目时，要求只有携带了有效token的设备才能连上来，且只能发布自己设备编号前缀的Topic。这种细粒度控制，在公共Broker上很难实现，但在MQTTnet里就是几十行代码的事。

第三是性能不差。MQTTnet底层走的是全异步IO模型，在单机场景下扛住几千个连接，每天处理上百万条消息一点问题没有。对绝大多数工厂、园区、车载场景来说，这个量级完全够用了。你真正需要担心的是自己写的业务回调阻塞了消息处理线程，而不是框架本身撑不住。

2. MQTTnet 核心原理：从协议到实现

2.1 别再被协议劝退：MQTT 最小必要知识

我见过不少同事一听到协议两个字就发怵，其实MQTT没你想的那么复杂。它本质上就是一套“邮局规则”：客户端把信写好，贴上Topic标签，扔进邮筒；服务端（Broker）根据Topic把信投递给所有订阅了这个标签的人。唯一特殊的地方在于，这套规则专门为低带宽、不稳定的物联网环境做了优化，所以报文特别精简，还支持断线重连、遗嘱消息这些实用功能。

你只需要理解MQTT里最核心的几个概念。Topic是消息的主题，可以按层级组织，比如 parking/camera/001/plate，支持用 + 匹配一层、用 # 匹配多层。QoS是消息的送达等级，0代表尽力发送，1代表至少送达一次，2代表恰好送达一次。Retain是保留消息，Broker会为每个Topic存一条最新消息，新订阅者一上来就能收到。Will Message是遗嘱消息，当设备异常断开时，Broker会代替它发布一条消息，通知其他系统“这个设备掉线了”。

这些概念搞清楚之后，你会发现MQTT的接入方式其实非常固定：设备端负责发布状态或事件，业务端负责订阅关心的Topic，服务端负责把两者连起来，再补上鉴权、存储、统计这些外围能力。而MQTTnet做的事情，就是把服务端这套“邮局系统”完整地实现出来，并且给你留好了各种扩展点。

2.2 MQTTnet 的架构与组件划分

MQTTnet的项目结构比较清晰，核心命名空间是 MQTTnet.Server，它负责处理连接监听、协议解析、会话管理、消息路由这些脏活累活。而 MQTTnet.Client 命名空间则提供了配套的客户端组件，方便你自己写测试程序，或者让终端设备通过MQTTnet接入。

从Broker视角看，MQTTnet启动后会监听一个TCP端口（默认1883），每来一个连接，它都会解析MQTT协议握手包，校验客户端ID、用户名密码、遗嘱消息等参数，然后维护该客户端的会话状态。之后所有客户端发布的消息，都由Broker按照Topic匹配关系路由给订阅者。这个过程完全在内存中完成，速度很快，且不依赖外部存储。

有意思的是，MQTTnet从设计上就把“可靠连接”和“业务处理”做了分离。它有自己的连接管理器、消息处理器和事件订阅机制，你也可以通过拦截器（Interceptor）在消息流转的各个环节插入自己的代码。比如在 InterceptingPublishAsync 里拦下每条发布消息做数据清洗，或者在客户端连接时通过 ValidatingConnectionAsync 做设备鉴权。这样的设计，让Broker能够无缝嵌入你的业务体系，而不仅仅是个消息转发器。

2.3 高性能从哪里来：异步模型与背压机制

我最早接触MQTTnet时也有个疑问：一个纯C#写的Broker，凭什么能支撑高并发？后来看了源码才明白，它几乎把异步的优势发挥到了极致。所有IO操作都基于async/await，没有同步阻塞的读写调用；底层用SocketAsyncEventArgs做无锁化的连接处理，配合线程池调度，尽量避免在热点路径上出现竞争。

更关键的是，MQTTnet处理消息时引入了类似背压（backpressure）的机制。当某个客户端消费速度跟不上时，Broker不会傻傻地一直往它对应的发送队列里塞消息，而是有 MaxPendingMessagesPerClient 这样的上限配置。超出后会根据策略丢弃最旧的消息，或者断开迟滞客户端，防止一个慢消费者拖垮整个服务。这种机制对于真实的物联网场景非常重要，因为现场设备性能参差不齐，总不能因为一个性能差的设备把整个Broker搞崩。

单从性能测试的结果来看，在一台普通配置的Windows服务器上，MQTTnet能轻松处理每秒上万条消息的转发，连接数也能稳定在数千级别。虽然和EMQX这种专门为百万连接设计的Broker还有差距，但对大多数C#项目而言，这个性能已经绰绰有余了，并且它换来了极高的定制性，这笔买卖很划算。

3. 实操：从零搭建一个 C# MQTT 服务端

3.1 环境准备：.NET 版本与 NuGet 依赖

开始之前，先把环境准备好。MQTTnet对.NET的版本支持比较广泛，.NET 6、.NET 7、.NET 8都没问题，老的.NET Framework 4.6.1以上也能跑，不过我更建议直接用.NET 6或以上版本，毕竟要对齐长期支持政策。如果你用的是Visual Studio，可以通过NuGet包管理器搜索 MQTTnet，一般直接安装最新稳定版即可。

我在写这篇文章时用的包版本是4.3.x。需要注意的是，MQTTnet从4.x开始对API做了不少调整，如果你在网上找到的是3.x的代码，可能会遇到方法名不匹配或者写法不同的问题。这种情况不要慌，优先参考当前版本自带的XML注释和GitHub上的Example工程。

创建一个控制台项目，或者ASP.NET Core空项目都可以。我个人习惯在解决方案里单独建一个 MqttBroker 项目，这样以后扩展成Windows服务或者Linux守护进程都方便。NuGet引用的核心包只有一个：MQTTnet。如果你要做依赖注入集成，可以再装 MQTTnet.AspNetCore，但基础场景先不用，保持干净。

3.2 30 行代码启动第一个 Broker

接下来就是见证奇迹的时刻。下面这段代码，是我实际用过的最简启动方式，项目引用里加上MQTTnet包后，直接运行就能得到一个可用的MQTT服务器：

csharp复制using MQTTnet;
using MQTTnet.Server;

var options = new MqttServerOptionsBuilder()
    .WithDefaultEndpoint()
    .WithDefaultEndpointPort(1883)
    .Build();

var mqttServer = new MqttFactory().CreateMqttServer(options);
await mqttServer.StartAsync();

Console.WriteLine("MQTT Broker 已启动，监听 1883 端口，等待客户端接入...");
Console.ReadLine();

await mqttServer.StopAsync();

这段代码默认监听所有本机IP的1883端口，没有开启任何认证，任何客户端只要能连到这台机器，都可以连接、订阅、发布。这在局域网联调时非常方便，但如果你把它暴露在公网或者办公网里，现在就等于是裸奔，后面必须把认证和权限补上。

我建议在正式开发时，务必明确绑定网卡IP，不要用默认的 0.0.0.0。如果你机器上有多个网卡，可以用 .WithEndpoint(“192.168.1.100”, 1883) 来指定监听地址，避免端口被外部无关请求扫描到。另外，如果端口被占用，启动时会抛异常，排查时优先确认是不是有别的程序占了1883。

3.3 加入连接校验、日志与消息拦截

一个只知道转发消息的Broker是没法上生产的，起码要加上三样东西：连接校验、事件日志、消息拦截。下面这段代码展示了如何在MQTTnet 4.x里完成基本接入：

csharp复制var options = new MqttServerOptionsBuilder()
    .WithDefaultEndpoint()
    .WithDefaultEndpointPort(1883)
    .WithConnectionValidator(context =>
    {
        if (context.ClientId != "allowed-client")
        {
            context.ReasonCode = MqttConnectReasonCode.NotAuthorized;
            return;
        }
        context.ReasonCode = MqttConnectReasonCode.Success;
    })
    .Build();

mqttServer.ValidatingConnectionAsync += e =>
{
    Console.WriteLine($"客户端 {e.ClientId} 正在尝试连接，用户名: {e.UserName}");
    return Task.CompletedTask;
};

mqttServer.ClientConnectedAsync += e =>
{
    Console.WriteLine($"客户端 {e.ClientId} 已连接");
    return Task.CompletedTask;
};

mqttServer.ClientDisconnectedAsync += e =>
{
    Console.WriteLine($"客户端 {e.ClientId} 已断开");
    return Task.CompletedTask;
};

mqttServer.InterceptingPublishAsync += e =>
{
    Console.WriteLine($"收到消息: Topic={e.ApplicationMessage.Topic}, Payload={Encoding.UTF8.GetString(e.ApplicationMessage.PayloadSegment)}");
    return Task.CompletedTask;
};

其中 WithConnectionValidator 是在握手阶段做校验，在这里你可以读取数据库中的设备列表，或者根据用户名密码鉴权。很多新手会跳过这一步，直接在 ValidatingConnectionAsync 事件里打日志，但要注意：ValidatingConnectionAsync 只是通知你“有客户端要进来了”，真正能决定它能不能连进来的逻辑，得放到 WithConnectionValidator 里设置 ReasonCode。这个细节我第一次用的时候就踩过坑，绕了一大圈。

消息拦截 InterceptingPublishAsync 是MQTTnet的精华所在。我经常用它来做数据清洗，比如把设备上传的原始数据解析成结构化对象后转发到另一个Topic，或者直接把数据异步写入时序数据库。你也可以在这里对消息做内容审计，但要注意别在回调里做耗时的同步操作，否则会拖慢消息处理链路，最好用 Task.Run 或者独立的消息处理服务来处理。

4. 上位机联调实战：发布订阅与服务端配合

4.1 用 C# MQTT 客户端完成接入自测

服务端跑起来之后，总得有客户端来测一测。MQTTnet同样提供了Client组件，用起来也很简单。你可以新建一个控制台程序，安装同一个 MQTTnet 包，然后写个简单的发布订阅Demo来验证端到端链路。

下面这段客户端代码，包含了连接、订阅、发布三个最基础的动作：

csharp复制using MQTTnet;
using MQTTnet.Client;

var factory = new MqttFactory();
using var client = factory.CreateMqttClient();

var options = new MqttClientOptionsBuilder()
    .WithTcpServer("192.168.1.100", 1883)
    .WithClientId("test-client-001")
    .WithCredentials("admin", "123456")
    .Build();

client.ApplicationMessageReceivedAsync += e =>
{
    Console.WriteLine($"收到消息: {e.ApplicationMessage.Topic} -> {Encoding.UTF8.GetString(e.ApplicationMessage.PayloadSegment)}");
    return Task.CompletedTask;
};

await client.ConnectAsync(options, CancellationToken.None);
await client.SubscribeAsync("parking/camera/+/plate", MqttQualityOfServiceLevel.AtLeastOnce);

while (true)
{
    Console.Write("输入要发布的消息内容: ");
    var content = Console.ReadLine();
    var message = new MqttApplicationMessageBuilder()
        .WithTopic("parking/camera/001/plate")
        .WithPayload(content)
        .WithQualityOfServiceLevel(MqttQualityOfServiceLevel.AtLeastOnce)
        .Build();
    await client.PublishAsync(message, CancellationToken.None);
}

这里有个非常容易踩的坑：MqttClientOptionsBuilder 里的 WithClientId 必须保证唯一。如果设备A和设备B用了同一个ClientId，后连接的客户端会把先连接的踢下线，然后两者反复抢占连接，造成“震荡重连”的现象。很多现场问题就是从这里来的，排查的时候先查ClientId是否重复。

另外，订阅的Topic里用了 + 通配符匹配多级中的某一层，这种写法在设备分组时非常实用。比如所有相机发布识别结果到 parking/camera/{相机编号}/plate，后台订阅 parking/camera/+/plate，就能收到所有相机的数据，而不用逐一订阅。

4.2 接入车牌识别相机等设备时的协议对接思路

现在很多主流车牌识别相机（包括海康、大华这些）都支持MQTT协议，或者在SDK里封装了MQTT推送能力。具体到停车场项目实战，通常的做法是让相机通过HTTP或SDK识别车牌后，把结构化数据（车牌号、抓拍时间、图片URL等）提交给一个中间服务，中间服务再以MQTT消息的形式推送到Broker，供岗亭客户端、收费系统、后台管理端实时消费。

为什么建议中间层用MQTT再转发一层？因为停车场的子系统太多了：入口控制机要接收识别结果、出口收费屏要显示缴费信息、管理后台要汇总流水、云端平台要同步数据。如果每个系统都直接连相机SDK，连接数会爆炸，而且相机的SDK往往不支持多路并发订阅。而中间层做一次转发，下游系统只需要订阅各自的Topic，互不干扰，多端扩展也容易。

对接中要注意几个细节。图片数据一般不要直接塞进MQTT消息体，MQTT适合传轻量控制指令和结构化小数据，图片建议先传到文件服务器或对象存储，消息里只携带URL。识别结果通常有一定的瞬时峰值，比如上下班高峰期，每台相机可能一秒内连续上报多辆车，Broker端要做削峰处理，比如把消息先丢进内存队列，再异步落库，避免数据库写入成为瓶颈。

4.3 用好 MQTTX 快速定位联调问题

联调阶段，强烈推荐你用MQTTX这个可视化客户端工具。它支持Windows、Mac、Linux，界面做得直观，能同时配置多个连接，手动订阅任意Topic，还能查看报文级信息，对排查协议层面的问题特别有效。

它的用法很简单：新建一个连接，填上Broker地址、端口、用户名密码，连接成功后就能看到发布和订阅的面板。我在现场排查问题时的习惯是，先用MQTTX订阅 #（所有Topic），看看设备到底有没有发数据、发到了哪个Topic、消息格式长什么样。这一步能快速判断问题是在设备端、网络端，还是服务端路由配置。

有一次客户反馈“上位机收不到相机数据”，我到现场第一件事就是用MQTTX订阅 #，结果发现消息其实一直在Broker上流转，只是发布Topic是 camera/001/push/result，而上位机订阅的是 parking/result，两边名字都没对上，自然收不到。这种问题如果不开MQTTX盲调，纯靠猜能把人逼疯。

5. 服务端扩展能力：认证、持久化与集群思路

5.1 用户名密码认证与多租户隔离

正式的商业项目里，不能让任何客户端都畅行无阻。我建议在服务器端至少做两层安全控制：连接时校验用户名密码，消息发布订阅时必须校验Topic访问权限。MQTTnet里，前者用 WithConnectionValidator 实现，后者可以结合 InterceptingSubscriptionAsync 和 InterceptingPublishAsync 订阅事件，动态判断客户端是否有权限。

这里提供一个简单的思路：建立一个设备表，每个设备一个唯一标识、一组用户名密码、一组允许访问的Topic前缀。客户端连接时，根据用户名密码校验身份；订阅或发布时，根据客户端ID查询它允许的Topic白名单，如果 Topic.StartsWith(允许前缀) 就放行，否则拒绝。这样即使某个设备被攻破，攻击者也只会被限制在它自己的Topic范围内，破坏不了整个系统。

如果你做的是多项目、多客户共用一个Broker，我建议在Topic命名上直接引入租户维度，比如 tenant1/device/001/data，然后在鉴权逻辑里读取客户端所属的租户ID，强制它只能发布和订阅以该租户前缀开头的Topic。这样一套Broker就能支撑多个独立业务，不用各搭一套，运维成本低很多。

数据库选型上，我见过工厂项目用SQLite就够，也有用MySQL的。关键在于鉴权逻辑不能写死在客户端，所有配置集中在服务端维护，这样设备入网、权限调整都不用重新部署客户端程序。

5.2 掉线消息不丢：QoS、Session 与持久化

设备在工地、停车场、移动车辆上跑，网络闪断是家常便饭，这就对会话恢复能力提出了要求。MQTT协议本身提供了两个机制来解决：一是QoS，二是Session持久化。

首先，发布端和订阅端要约定好QoS等级。如果业务上不允许丢消息，建议用QoS1，它保证消息至少送达一次。QoS2虽然不重复，但吞吐量会差一些，对于大多数物联网上报场景没有太大必要。订阅端如果想要断线期间的消息不丢，必须设置 WithCleanSession(false)，否则Broker会认为每次连接都是新会话，离线期间不会缓存任何消息。

MQTTnet服务端对Session的处理，默认支持断线恢复，并且提供了消息过期时间的配置 WithDefaultMessageExpiryInterval，你可以为每条消息设置有效期。比如设备离线5分钟，它关心的控制指令在5分钟后自动作废，避免设备重新上线后收到一堆过期指令。这是一个很实用的细节。

如果业务量再大一点，想做到Broker重启后消息不丢，就需要引入持久化存储了。MQTTnet本身没有内置数据库持久化，但你可以在 InterceptingPublishAsync 里把消息转发到消息表或者队列系统。我的做法是，在拦截事件里把原始消息写入Redis的Stream，然后由后台消费者统一落库，Broker本身不关心存储细节，保证了转发速度。

5.3 水平扩展：从单机到网关/代理层

单机MQTTnet最怕的不是消息量大，而是单点故障。真到了生产环境，我建议至少部署成主备或者负载均衡模式。不过MQTT协议本身的集群化比较麻烦，因为消息要维持会话一致性，光靠Nginx转发TCP解决不了Session同步问题。

一种务实做法是用“边缘Broker + 中央Broker”的两级结构。每个现场部署一台MQTTnet边缘Broker，负责本地的设备和上位机通信；边缘Broker再把关键数据转发给中央机房的中心Broker做汇总。这种模式的好处是，现场断网不影响本地业务，网络恢复后再自动同步数据，非常适合停车场、工厂这种有多个独立站点的场景。

如果要做更高可用，可以结合容器编排平台，把MQTTnet部署成多副本，前面挂负载均衡，然后给Broker配置状态存储。但这套方案的复杂度会明显上升，牵扯到会话路由和消息持久化的网络同步，已经不是普通项目需要面对的领域了。我自己的经验是，先用两级结构解决90%的问题，剩下的再考虑集群。

6. 高频问题排查实录

6.1 客户端 ID 冲突：互踢与反复重连

这是我排查过最多的一类问题，症状是：设备上线后过一会儿就掉线，然后又自动连上，反复循环，整个系统看起来在抽风。打开服务端日志，会看到同一ClientId连了断、断了连。后面不用怀疑，基本就是两个以上客户端用了同一个ClientId。

解决办法也简单，做到以下几点就够了：每个设备出厂时烧录唯一序列号作为ClientId；如果客户端是软件，就在连接时用GUID加设备类型生成，比如 camera-001、plate-gateway-002。另外，给Broker加个客户端的连接记录，联调时打开 ClientConnectedAsync 和 ClientDisconnectedAsync 日志，几秒钟就能看出谁在重复连接。

6.2 消息收不到或者延迟大

消息收不到，我习惯从三个层面排查：第一个层面是网络，用MQTTX或telnet先确认TCP端口通不通，如果端口不通，检查防火墙、云安全组、宿主机端口映射；第二个层面是Topic，确认发布方和订阅方的Topic字符串完全一致，通配符是否正确匹配，这一点用MQTTX订阅 # 一把梭最直观；第三个层面是权限，确认订阅者在服务端鉴权逻辑里没有被拒绝。

消息延迟大的问题，很多时候是Broker所在服务器的网络带宽被打满了。比如视频流的图片数据如果走MQTT，再大的带宽也不够用。这时应该检查有没有客户端在疯狂发布大Payload消息，或者订阅关系是否出现了消息风暴。解决方案就是把大报文改成引用消息，只让MQTT走轻量控制。

6.3 QoS 0 与 QoS 1 混用带来的坑

有些设备端用MQTT库时，把发布QoS默认设为0，你很难保证每条消息都可靠送达。如果业务对完整性要求高，一定要在设备端把QoS提到1，除了发布时报文会稍大、网络开销略高之外，没有别的明显弊端。订阅端的QoS等级，决定Broker能给订阅者推送的最高等级，如果订阅端设的是0，就算发布端发的是QoS1，消息依然不会重发。

另一个坑是，很多新手把QoS1当成“一定会按顺序到达”，这在网络重连频繁时并不成立。所以业务逻辑里如果对顺序有严格要求，需要自己在消息体里带一个自增序号，接收端做顺序校验，不能只依赖协议层。

6.4 高并发场景调优与资源限制

如果你确实要把MQTTnet推到更高的并发量，可以调整这些参数试试。连接层，适当提高操作系统的TCP端口范围，调整 MaxPendingMessagesPerClient，避免慢消费者积压消息。消息处理层，尽量保证自己的业务回调快速返回，不要在 InterceptingPublishAsync 里同步写文件、同步查数据库。服务运行层面，把Broker部署为独立的服务进程，预留足够的内存，别和吃资源的上位机控制台塞在同一个进程里。

我最后想说的是，别把所有希望都寄托在Broker的性能上。真实项目里，瓶颈往往出现在数据库写入或者边缘设备的处理能力上。MQTTnet能帮你把消息链路做得很高效，但业务的削峰填谷还是得靠系统设计，比如队列缓冲、批量写入、数据压缩这一套。

每当我回头再看这个开源项目，都觉得当初选择在C#技术栈里用MQTTnet自建Broker，是个非常正确的决定。你不会再被商用产品的授权费用绑住手脚，也不会因为对接不上内部系统而到处求人。把服务端源码拿在手里，改起来是踏实的，用起来是自由的。如果你正在设计下一套设备接入系统，真心建议先拿MQTTnet跑一个原型试试，那个从“通讯靠猜”到“消息自己会来”的转变过程，只有亲手做过的人才知道有多爽。