Routing Key由生产者在basic_publish中指定，是消息自带的字符串标签；Binding Key由queue_bind设置，是Exchange与Queue绑定时定义的匹配规则，二者语义和作用均不同。
RabbitMQ里Routing Key和Binding Key不是一回事，混淆它们是消息路由失败最常见原因。
Routing Key 是谁填的、填在哪
Routing Key 由生产者在 channel.basic_publish() 时显式指定，是消息自带的一个字符串标签，比如 "order.payment.success" 或 "user.created"。它不决定消息发到哪个队列，只提供一个“线索”——交换机拿它去跟 Binding Key 对比。
- 长度不能超过 255 字节，超长会被截断或报错
PRECONDITION_FAILED - routing key too long - 在 direct exchange 下必须与 Binding Key 完全相等才匹配；在 topic exchange 下才参与通配符匹配（
*和#） - fanout exchange 完全忽略 Routing Key，所有绑定队列都会收到
Binding Key 是谁设的、设在哪
Binding Key 是队列绑定到 Exchange 时定义的规则，通过 channel.queue_bind() 设置，比如 routing_key="order.*" 或 routing_key="user.#"。它属于 Binding 关系的一部分，本质是“这个队列愿意接收哪些 Routing Key 的消息”。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- Binding Key 不是队列属性，而是 Exchange 和 Queue 之间的绑定关系属性
- 同一个 Exchange 可以有多个 Binding，每个 Binding 可带不同 Binding Key，指向不同队列
- headers exchange 不用 Binding Key，改用消息 header 字段匹配，但基本没人用
匹配失败的典型现象和排查点
消息发出去却没进队列，或者进了不该进的队列，大概率是这两个 Key 没对齐。
- 用
rabbitmqctl list_bindings查看实际 Binding：注意输出中第三列是routing_key字段，它就是 Binding Key 的值 - direct exchange 下写成
binding_key="order.payment.*"—— 错！*在 direct 里就是字面量，不会通配，只会匹配字面等于"order.payment.*"的 Routing Key - topic exchange 下 Routing Key 里用了
/或空格 —— 错！topic 要求 Routing Key 只能含字母、数字、点（.）、连字符（-）和下划线（_），否则匹配永远失败 - 大小写敏感：Routing Key 是
"Order.Created"，Binding Key 是"order.created"→ 不匹配
真正容易被忽略的是：Binding Key 的语义取决于 Exchange 类型，而不是你“觉得它该干嘛”。写死一个 routing_key 参数，却不确认当前 Exchange 是 direct 还是 topic，是线上路由问题最隐蔽的根源。
