MQTT 5.0 消息重试与Reason Code确认规则关联疑问

MQTT 5.0规范中有两处相关表述：其一规定「若收到携带0x80及以上Reason Code的PUBACK或PUBREC，对应的PUBLISH报文将被视为已确认」；其二在Reason Code章节指出「小于0x80的Reason Code表示操作成功完成，常规成功返回码为0，0x80及以上的Reason Code表示操作失败」。

问题1：为何0x80及以上的Reason Code代表操作失败，但携带该区间Reason Code的PUBACK仍被视为已确认？ #

这两个规则看起来冲突，本质是混淆了两个完全独立的判断维度：报文传输确认和业务操作结果。
PUBACK/PUBREC的核心作用是终结对应PUBLISH报文的QoS传输流程，避免发送端无意义的超时重发。当接收端返回0x80及以上的失败Reason Code时，实际含义是「我已经收到了你发的这条报文，但因为权限不足、主题不存在、配额耗尽等原因没法完成后续业务处理」，这种场景下发送端就算重发一百次，接收端还是会处理失败，所以直接标记为已确认，终止传输流程，避免浪费带宽和连接资源。
Reason Code的成功/失败标识，只代表接收端对报文内容的业务处理结果，和是否需要继续传输报文没有必然关联。

问题2：除此以外，是否意味着携带小于0x80的Reason Code的PUBACK会被视为未确认？ #

这个推论完全是错误的。
小于0x80的Reason Code本身就是常规成功确认的标识，代表接收端不仅收到了PUBLISH报文，还顺利完成了对应的业务处理，这种场景下的PUBACK当然属于有效确认，甚至是最常见的成功确认。
规范中特意单独提及0x80及以上Reason Code的PUBACK属于确认，只是对异常场景的补充说明，怕开发者误以为只有成功返回码才算确认，失败码就不算需要重发，并不是否定常规成功返回码的确认效力。小于0x80的返回码属于默认生效的确认状态，不需要额外单独说明。

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