在基于 TCP 实现消息队列的客户端与服务端通信时，自定义应用层协议是保障跨网络调用 VirtualHost 核心 API、实现可靠通信的关键。不同于 HTTP、JSON 等文本协议，消息队列交互的 Message 本身是二进制数据，这要求协议设计既要适配二进制传输的特性，也要清晰划分客户端与服务端的职责边界。本文结合实际设计板书，重点分析协议设计中 "回调函数不纳入传输参数" 的底层逻辑，以及响应信息类设计的核心思路。
一、自定义应用层协议的基础架构
在消息队列的通信模型中，客户端（生产者 / 消费者）与 Broker Server 之间的所有交互，都基于 "请求 - 响应" 的二进制协议格式完成，协议结构分为请求和响应两部分，核心由type、length、payload三个字段构成：
type（4 字节）：标识当前请求 / 响应对应的核心 API，比如 0x01 代表创建 channel、0x03 代表创建 exchange、0x09 代表订阅 message 等，本质是明确 "要调用哪个 API"；
length（4 字节）：标识payload的长度，用于解析二进制数据；payload：二进制数据体，内容随type和 "请求 / 响应" 类型动态变化 ------ 请求的payload是对应 API 参数的序列化结果，响应的payload是 API 调用结果的序列化内容。
以创建交换机（exchangeDeclare）为例：客户端发起请求时，type设为 0x03，payload是ExchangeDeclareArguments（包含交换机名、类型、持久化标识等）的序列化数据；服务端处理完成后，响应的type仍为 0x03，payload则是该 API 调用结果（成功 / 失败）的序列化内容。
这一架构的核心目标，是让客户端能通过网络 "远程调用" 服务端的 VirtualHost 核心 API，同时服务端能精准反馈调用结果。
二、为何回调函数不纳入跨网络传输参数
在消费消息（订阅队列）的场景中，客户端调用 "订阅 message"（0x09）API 时，需要指定回调函数 ------ 该函数会在客户端收到服务端推送的消息时触发，执行具体的业务逻辑。但从协议设计逻辑来看，客户端无需也不能将回调函数传递给服务端，核心原因有三点：
1. 回调函数的 "本地执行" 属性
回调函数的核心作用是 "在客户端本地处理消息"，其逻辑是客户端业务层的专属实现（比如解析消息体、执行业务逻辑、记录日志等），服务端的职责仅为 "投递消息"，而非 "执行客户端的业务逻辑"。板书中标注 "客户端不需要把自己要执行的业务回调告诉服务器"，正是基于这一职责边界：服务端只需要确认 "客户端订阅了队列"，并将消息推送给客户端即可，至于客户端收到消息后如何处理，完全是客户端本地的事情。
2. 服务端的核心职责是 "投递" 而非 "处理"
消息队列 Broker Server 的核心能力是消息的存储、路由和投递，而非执行客户端的业务逻辑。在订阅流程中，服务端只需执行basicConsume完成订阅关系的建立，然后将消息推送给客户端；回调函数的触发和执行，完全由客户端在收到消息后自行处理，这既符合 "服务端轻量化" 的设计原则，也避免了服务端耦合客户端的业务逻辑。
三、响应信息类设计：为客户端提供明确的调用反馈
既然回调函数留在客户端本地，服务端就需要通过清晰的响应信息，让客户端知晓 "API 调用是否成功""推送的消息内容是什么"，因此协议设计中专门定义了响应信息类（基于BasicReturns扩展），核心逻辑如下：
1. 基础响应类：BasicReturns 的核心字段
BasicReturns作为所有响应的基类，封装了跨 API 通用的核心标识：
rid：请求唯一标识，用于关联 "请求 - 响应"，确保客户端能将响应与发起的请求一一对应；channelId：通信通道标识，适配 "一个 TCP 连接（Connection）包含多个逻辑通道（Channel）" 的设计，精准定位响应所属的通道；ok：请求处理结果（成功 / 失败），核心反馈 API 调用的最终状态。
这些字段被序列化后存入响应的payload，客户端解析后能快速判断 "调用是否成功""对应哪个请求"。
2. 业务扩展响应类：适配不同 API 的个性化需求
针对不同的type（API），在BasicReturns基础上扩展专属响应类。比如订阅消息的响应，除了基础的rid、channelId、ok，还需包含consumerTag（消费者标识）、basicProperties（消息属性）、body（消息体）等字段 ------ 这些内容是客户端触发回调函数的核心数据，服务端通过扩展响应类将其传递给客户端，客户端解析后即可调用本地回调函数处理消息。
结语
自定义应用层协议的设计，本质是在二进制传输的基础上，平衡 "通用性""灵活性" 和 "职责边界"。不传输回调函数是对客户端与服务端职责的合理划分，而响应信息类的设计则是对 "客户端需要明确反馈" 这一需求的精准满足。这一设计思路不仅适配消息队列的通信场景，也为基于 TCP 的自定义协议设计提供了可参考的核心逻辑 ------ 让协议既满足技术传输的要求，又贴合业务交互的本质。