MQTT客户端断开后不会自动重连，需注册DisconnectedHandler并在其中调用await ConnectAsync，配合指数退避策略、重试上限及ConnectedHandler中处理订阅。
MQTT客户端断开后不自动重连？检查 ConnectAsync 是否被重复调用
很多 C# 项目用 MQTTnet 库，但写完连接逻辑就以为万事大吉——其实 ConnectAsync 是一次性操作，断线后它不会自己再跑一遍。你得主动监听断开事件并触发重连。
-
MqttClient的DisconnectedHandler必须提前注册，且 handler 内部要调用ConnectAsync（别漏 await） - 直接在
DisconnectedHandler里递归调用重连函数容易堆栈溢出，改用Task.Run或await Task.Delay后再连 - 别在
ConnectAsync外层包 try-catch 就完事——失败时要区分是网络超时、认证失败还是服务器拒绝，Exception.InnerException?.Message常比外层异常更有用
重连间隔越来越短，最后把服务器打挂？控制退避策略
指数退避不是可选项，是物联网场景的生存底线。连续快速重连不仅无效，还可能触发服务端限流或 IP 封禁。
- 从 1 秒开始，每次失败翻倍，上限建议设为 30–60 秒，用
TimeSpan.FromSeconds(Math.Min(60, Math.Pow(2, retryCount))) - 别用
Thread.Sleep阻塞主线程，C# 中一律用await Task.Delay - 重试次数达到阈值（比如 5 次）后，应停止自动重连，转为记录日志并通知上层（例如发个本地事件或写入状态变量
IsConnected）
为什么重连成功了，但 SubscribeAsync 却报 “client not connected”？
MQTTnet 的订阅必须在连接建立完成之后执行，而 ConnectAsync 的完成不代表所有内部状态已就绪——尤其在重连场景下，容易误判“已连上”就立刻发订阅。
- 务必等
ConnectAsync的Task完全完成（await 到底），再调用SubscribeAsync - 不要在
DisconnectedHandler的回调里直接订阅；应在重连成功的回调中（比如ConnectedHandler）统一处理订阅逻辑 - 如果用了 Clean Session = false，重连后服务器会恢复之前的订阅关系，此时重复调用
SubscribeAsync可能被忽略，但不会报错——这反而更难排查
Windows 服务或后台程序中重连失效？检查线程上下文和生命周期
桌面程序里看着好好的重连逻辑，一放到 Windows Service 或 ASP.NET Core 后台服务里就静默失败，大概率是线程模型或对象生命周期没兜住。
-
MqttClient实例不能是局部变量，必须作为类成员长期持有，并确保单例复用（多次 new 会导致旧连接残留+新连接无管理） - Windows Service 的
OnStart中启动 MQTT 连接没问题，但若用async void OnStart，异常会被吞掉——必须用同步包装或记录全局异常处理器 - ASP.NET Core 中推荐注入
IMqttClient并配合IHostedService管理启停，避免在 Controller 里临时连/断
真正麻烦的不是连不上，而是连上了却没收到消息、或重连后 QoS 0 消息莫名丢失——这些往往卡在 Clean Session、Will Message、甚至 Broker 端配置上，得一层层对齐两端行为，不能只盯着客户端代码。
