这更像是一个一般性的问题，但在不同的客户端或协议版本中，甚至可能在服务器版本中，它可能会得到不同的处理。
所以我在这里说的是QOS 2级订阅。在这种情况下，按顺序处理数据包。既然有一个确认协议，这意味着在第一条消息被确认之前，下一条消息无法处理？或者它的订购只是为了接收，而不是为了确认？
如果通过确认施加反压力，这与通配符主题有何关系？有"；订单；实际上，它只是一个真正的概念，适用于包含主题的个人，而不是整个通配符。那么，这是否意味着背压也在每个主题的基础上处理，或者它是在整个通配符订阅的基础上维护的？
编辑：
所以我用HiveMQ和Misquito做了一些测试。这两者都有相同的行为：一旦你没有对QOS2数据包调用回调，整个过程就会停止对任何东西的响应。它甚至似乎与通配符也没有任何关系。
因此，作为一项测试，我有三个主题：test/1、test/2和test2/1
test/2消息永远不会得到确认。
我试着窃听这个问题，看看发生了什么。在我向test/2发送消息后会发生什么，无论主题是什么，后续消息都不会发送到通配符订阅者。这意味着通配符订阅实际上并不关心底层主题语义。情况似乎更糟：如果我将通配符订阅拆分为两个单独的订阅，那么对于test/1和test/2，情况完全相同。任何QOS>未释放的0数据包将阻塞整个连接！因此，这似乎并不表明客户端存在直接问题，但已经是与服务器相关的问题。因此，我最初的问题再次出现：这是否符合规范，或者这只是一个实现安全性
QOS发生在发布到单个主题的单个消息的上下文中。
每当在任何通配符主题上发布消息时，通配符订阅都会在客户端中导致回调，但QOS机制只关心保证在单个主题上发布的单个消息的QOS。
接收客户端订阅了多个主题这一事实与处理QOS无关。