关于MqttNet中ApplicationMessageProcessedAsync等事件的疑问

一、ApplicationMessageProcessedAsync 事件的存在原因 #

ApplicationMessageReceivedAsync 是客户端刚从 Broker 拿到消息就触发的，此时还没完成 MQTT 协议层面的收尾操作；而 ApplicationMessageProcessedAsync 是在客户端完成所有内部处理逻辑后才触发的。

举个具体的例子：

• 对于 QoS 1 的消息，Received 触发时，客户端还没给 Broker 发送 PUBACK 确认；等发送完 PUBACK、更新完内部消息状态缓存后，才会触发 Processed。
• 对于 QoS 2 的消息，Processed 会在完成整个“收到消息→发 PUBREC→收 PUBREL→发 PUBCOMP”的闭环流程后触发。

这个事件的核心作用是给你一个最终确认节点：你可以确定这条消息已经在客户端侧完成了全流程处理，包括协议层面的确认动作，不会再因为网络重试、客户端缓存逻辑产生后续变动。比如做消息消费统计时，在 Processed 里计数能避免重复统计（Broker 重发的消息不会重复触发这个事件）。

二、ApplicationMessageSkippedAsync 的触发场景及与处理的关联 #

客户端会跳过消息的常见场景：

• 订阅关系失效：客户端已取消某个主题的订阅，但 Broker 仍发来该主题的消息，会直接跳过
• 重复消息过滤：QoS 1/2 的消息因 Broker 未收到确认而重发，客户端内部已记录过该消息的 MessageId 并确认处理完成，会跳过重复投递
• 订阅未恢复完成：客户端断开重连后，还没完成订阅主题的恢复操作，此时收到的消息会被跳过
• 不符合过滤规则：如果客户端配置了自定义消息过滤器（比如主题前缀、Payload 格式过滤），不符合规则的消息会被跳过
• QoS 级别不兼容：比如客户端仅支持 QoS 0，但收到 QoS 2 的消息且配置为不处理该级别时，会跳过

关于跳过与处理的关联：
大部分跳过场景是在消息进入业务处理流程前发生的——也就是消息根本不会触发 Received 和 Processed 事件，因为客户端判断这条消息无需交给业务逻辑处理。只有重复消息的情况和之前的处理直接相关：因为已经处理过一次，所以第二次收到时跳过，避免重复执行业务逻辑。

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