MQTT协议规范中为何不支持订阅时为主题设置别名？

首先先纠正一个常见误解：MQTT v5.0 现有主题别名(Topic Alias)机制本身已经支持双向使用，并非只能用于客户端向Broker发送PUBLISH报文的场景：只要接收方（客户端或Broker）在连接建立阶段的CONNECT/CONNACK报文中声明主题别名最大值大于0，发送方就可以在发往该接收方的PUBLISH报文中使用别名替换完整主题名，完全覆盖你提到的「Broker向订阅者推送消息时用别名节省带宽」的需求。

协议没有单独在订阅流程中增加别名分配逻辑，主要有以下几个原因：

• 符合协议分层设计的权责边界
  现有主题别名的设计原则是别名由发送方分配、接收方仅维护映射关系，不需要额外的协商报文开销。如果把别名分配逻辑放到订阅流程中，会额外增加SUBSCRIBE/SUBACK报文的复杂度，也打破了现有别名机制的通用设计。
• 避免Broker侧不必要的额外开销
  MQTT协议的核心设计目标之一是尽量降低Broker侧的资源消耗，适配海量客户端连接的场景。如果要求Broker在订阅阶段为每个客户端的每个订阅分配、存储别名映射，对于支持百万级连接、单客户端订阅数十上百个主题的集群来说，内存开销会大幅上涨，反而得不偿失。
• 无法兼容通配符订阅、共享订阅等特性
  MQTT支持通配符订阅（比如a/#）、共享订阅（比如$share/group/a/b/c），单个订阅可以匹配多个不同的具体主题，无法为单个订阅分配唯一别名对应所有匹配的主题，会导致客户端收到别名报文后无法对应到原始主题，完全失去可用性。
• 应用层可灵活实现定制化需求
  如果你有非常明确的、需要订阅时固定绑定别名的场景，完全可以在应用层自行协商别名映射规则，不需要协议层做标准化支持，这也符合MQTT尽量保持内核简洁、灵活度留给上层实现的设计思路。

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