Direct交换机要求routingKey与绑定键完全精确匹配，Topic交换机支持*（单词）和#（多单词）模式匹配；二者类型不可混用，选型取决于路由是否需扩展性。
Direct交换机只认完全相同的routingKey
消息发出去时带一个字符串，比如 "user.register"；队列绑定到 Direct 交换机时也必须指定一个绑定键，比如 "user.register"。只有这两个字符串逐字节相等，消息才进队列。哪怕多一个空格、大小写不一致、少个点，都不匹配。
常见错误现象：
- 生产者发了
"user_register"，消费者绑的是"user.register"→ 消息被丢弃（默认行为） - 多个队列绑了同一个
bindingKey，比如都绑了"payment.success"→ 消息会复制一份发给每个队列（不是轮询）
适用场景：任务分发到固定处理模块，例如订单创建、支付回调、短信发送各自走独立队列，路由键就是硬编码的业务标识。
Topic交换机用*和#做模式匹配
* 匹配一个单词（以 . 分隔），# 匹配零个或多个单词。比如绑定键 "log.*.error" 能收到 "log.db.error" 和 "log.api.error"，但收不到 "log.system.memory.warn"（因为中间多了两个词）；而 "log.#" 就能匹配后者。
容易踩的坑：
- 绑定键里不能出现空格或特殊字符（如
@、/），只允许字母、数字、.、*、# -
"#"开头的绑定键（如"#.alert"）是合法的，但实际很少用；更常见的是"order.*.status"或"sensor.#" - 如果多个队列绑了重叠的模式（如
"log.*"和"log.#"），同一条消息可能同时进多个队列——这不是 bug，是设计如此
性能影响：当绑定键数量超过几百个且大量含 # 时，RabbitMQ 内部匹配耗时会上升，但日常业务中几乎感知不到。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
别在同一个交换机上混用两种语义
Direct 和 Topic 是两种交换机类型，不是配置项。你声明一个交换机时就必须指定类型：channel.exchangeDeclare("ex", BuiltinExchangeType.DIRECT) 或 channel.exchangeDeclare("ex", BuiltinExchangeType.TOPIC)。不存在“让 Direct 支持通配符”或“让 Topic 做精确匹配”的中间态。
典型误操作：
- 以为把 Topic 交换机的绑定键写成
"order.pay"就等价于 Direct → 实际上它依然按 Topic 规则匹配，只是碰巧没用通配符 - 在代码里复用同一个交换机名称，但前后两次声明类型不同 → RabbitMQ 会报错
PRECONDITION_FAILED - inequivalent arg 'type' for exchange - 用 Spring AMQP 时，在
@RabbitListener绑定队列时漏写binding.key，导致队列绑到了空字符串上 → Topic 下收不到任何消息（因为""不匹配任何非空routingKey）
选型关键看路由是否需要扩展性
如果业务路由规则未来基本不变，比如就那几个固定事件类型（"email.send"、"sms.send"、"push.notify"），Direct 更轻量、语义清晰、出错好排查。
如果要支持多维度订阅，比如日志系统要按「服务名.模块名.级别」三级过滤，或者 IoT 设备消息按「区域.设备类型.状态」组合分发，Topic 的模式匹配就是刚需。
真正容易被忽略的一点：Topic 的灵活性是以理解成本为代价的。团队里有人把 "*" 当成正则里的 .*，或者以为 "#" 能跨层级跳过中间段，这类误解会在测试环境埋下静默丢失消息的隐患。
