作为常年跟MQTT打交道的开发者，这两个问题都是日常使用中高频碰到的，我来给你拆解一下解决方案：

1. 如何通过MQTT判断远程设备是否在线？ #

判断设备在线状态，MQTT协议本身就提供了几种可靠的方式，按优先级推荐：

• MQTT遗嘱消息（LWT）——最可靠的原生方案
  这是MQTT专为设备异常离线设计的机制。设备客户端在发起连接时，提前配置好LWT参数：

  • 指定一个离线通知主题（比如device/device001/status）
  • 设置离线消息内容（比如"offline"）
  • 选择QoS级别（建议用QoS 1，保证离线通知能被订阅者收到）
  • 开启保留标志（让新订阅者也能获取到最新的设备状态）
    当设备因为网络中断、程序崩溃等异常情况断开连接时，MQTT Broker会自动向预设主题发布离线消息。而设备在线时，你可以让它主动向同一主题发送"online"消息（同样带保留标志），这样订阅该主题的服务或设备就能实时掌握状态。

• 基于Keep Alive的心跳与Broker系统主题
  MQTT协议的Keep Alive参数允许客户端设置一个时间间隔（比如60秒），客户端需要在这个间隔内给Broker发送至少一个消息（可以是PINGREQ心跳包，也可以是业务消息）。如果Broker在1.5倍Keep Alive时间内没收到客户端的任何数据，就会判定设备离线。
  很多主流Broker（比如Mosquitto、EMQX）会提供系统主题，你可以订阅类似$SYS/brokers/+/clients/+/connected的主题，就能收到设备连接/断开的状态通知。另外，设备也可以主动定期向状态主题发送心跳消息，订阅者如果超过指定时间没收到心跳，就可以判定设备离线。

• MQTT 5.0会话状态通知
  如果你的Broker和客户端都支持MQTT 5.0，可以利用协议新增的会话状态通知功能，客户端可以请求Broker在会话终止时发送通知，或者订阅更细粒度的状态主题来获取在线状态变化。

2. 使用MQTTfx发布消息后未收到确认，回调仅获取到负载数据的处理方案 #

这个问题其实分两部分：没收到确认、回调只返回负载，咱们逐个解决：

• 先确认QoS级别设置——核心原因
  MQTT的QoS 0是「最多一次」传输，协议本身就不会返回PUBACK确认消息！如果你发布时用的是QoS 0，没收到确认是完全正常的。想要收到确认，你需要在MQTTfx发布消息时，把QoS改成1（至少一次）或者2（恰好一次），这两个级别下，Broker都会返回对应的PUBACK（QoS1）或PUBREC/PUBREL/PUBCOMP（QoS2）确认报文。

• 查看MQTTfx的日志获取确认信息
  MQTTfx的消息回调默认只返回业务消息的负载，而发布消息的确认属于控制报文，不会出现在普通消息回调里。你可以切换到MQTTfx界面的Logs标签页，这里会记录所有客户端和Broker之间的报文交互，包括你发布消息后收到的PUBACK确认。另外，你也可以在MQTTfx的Settings里开启「显示ACK消息提示」，这样收到确认时会有弹窗或界面提示。

• 排查Broker连接与配置
  先确认MQTTfx和Broker的连接状态是否稳定：在Connection标签页看是否显示Connected，如果有频繁重连，可能消息根本没发送成功，自然收不到确认。你可以尝试重新连接Broker，或者换一个公共测试Broker测试，排除Broker本身的配置限制（比如部分私有Broker可能禁用了QoS1/2）。

• 明确回调的作用范围
  要注意：MQTTfx的「消息回调」是用来接收你订阅主题的业务消息的，发布消息的确认属于客户端和Broker之间的控制信令，本来就不会出现在这个回调里。如果需要在代码层面处理确认逻辑，建议用更灵活的MQTT客户端库（比如Eclipse Paho），但如果只是用MQTTfx做模拟测试，通过日志查看确认就足够了。

内容的提问来源于stack exchange，提问作者Bipin