消息结构设计需精简消息体、复用amqp属性、选择高效序列化方式并按需压缩。应剔除冗余字段，用扁平json替代嵌套pojo；利用headers、correlationid等原生属性传递元数据；避免jdk序列化，小文本可选zlib压缩。
消息结构设计直接影响序列化体积和网络传输效率。Java客户端发送消息时，RabbitMQ底层需将消息体（body）和属性（properties）序列化为字节流，再通过AMQP协议传输。结构越冗余、类型越复杂，序列化后体积越大，带宽占用越高，尤其在高频小消息场景下，开销会被显著放大。
精简消息体，避免嵌套与冗余字段
消息体应只包含消费者真正需要的业务数据，剔除注释性字段、空值字段、重复标识字段（如已在路由键中体现的业务类型）。优先使用原始类型或扁平JSON，避免深层嵌套对象或通用Map结构。
- 推荐：用字符串拼接或轻量JSON（如Gson.toJson(new OrderSummary(id, status, amount))），而非完整Order实体类序列化
- 避免：直接序列化含Hibernate代理、Spring上下文引用、日志对象等的复杂POJO
- 示例对比：不推荐发送
{"order":{"id":"123","user":{"name":"A","email":"a@b.com","address":{...}}}}；推荐发送{"orderId":"123","status":"paid","amount":99.9}
复用消息属性，减少body膨胀
RabbitMQ的AMQP.BasicProperties提供标准元数据字段（如contentType、correlationId、replyTo、headers），这些字段在协议层原生支持，无需参与body序列化，比塞进JSON里更高效。
- 用
headers传递路由标识、版本号、租户ID等上下文信息，而非写入body - 用
correlationId替代body内自定义请求ID字段 - 设置
contentType = "application/json"或"text/plain"，避免消费者盲目解析
按场景选择序列化方式
默认使用JDK序列化效率低、体积大、有安全风险，应主动替换：
- 小文本消息（String.getBytes(StandardCharsets.UTF_8)，零序列化开销
- 结构化数据：选用Protobuf或Avro，比JSON小30%~50%，且有强Schema约束
- 若必须用JSON：禁用null字段输出（Gson设置
serializeNulls(false)），启用压缩（见下条）
启用消息级压缩（谨慎使用）
对>10KB的消息体，在发送前压缩可显著减小网络负载，但会增加CPU开销。需权衡网络瓶颈与CPU资源：
- 仅对body压缩，properties保持明文（AMQP头不可压缩）
- 使用
java.util.zip.Deflater（zlib）比gzip更轻量，适合高吞吐场景 - 消费者端需识别
contentEncoding="deflate"并自动解压，避免硬编码逻辑 - 注意：压缩对短文本无效，甚至可能略微增大体积
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
