该错误由spring amqp客户端校验触发，非rabbitmq服务端抛出；因传入null、空串或含非法字符（如空格、斜杠、控制符）的routingkey，违反amqp协议对routingkey必须非空、长度≤255、仅含ascii可见字符（u+0021–u+007e）的要求。
直接说结论：这个错误不是 rabbitmq 服务端抛的，而是 spring amqp 客户端在构造 message 或调用 rabbittemplate.convertandsend() 时，传入了非法的 routingkey —— 比如为 null、空字符串 ""、或包含控制字符/斜杠以外的非法符号（如 、 、\、.. 等）。
为什么 routingKey 为空或非法会报这个错
RabbitMQ 协议要求 routingKey 是 AMQP 中一个严格校验的字段：它必须是非空、非空白、长度 ≤ 255 字节、且只允许 ASCII 可见字符（U+0021–U+007E），不能含 /、\、^、~、?、*、 （空格）等。Spring AMQP 在发送前会做预检，不满足就直接抛 IllegalArgumentException: Invalid routing key format，根本不会发到 Broker。
常见触发场景：
- 硬编码写成
template.convertAndSend("exchange", "", message) - 从 HTTP 请求参数或数据库字段动态拼接，但没判空或 trim，比如
request.getParameter("type").trim()返回空串 - 使用 SpEL 表达式如
@rabbitTemplate.convertAndSend('my.exchange', #root.payload.type, #root.payload)，而payload.type是null
RabbitTemplate.convertAndSend() 的三个重载签名怎么选
容易混淆的是这三个方法对 routingKey 的约束不同，选错就会踩坑：
-
convertAndSend(String exchange, String routingKey, Object message)→ 要求routingKey必须非空有效，否则立刻报错 -
convertAndSend(String exchange, String routingKey, Object message, CorrelationData correlationData)→ 同上，routingKey校验逻辑完全一致 -
convertAndSend(Object message)（无参重载）→ 使用默认 exchange 和默认 routingKey（即空字符串""），但此时若队列是通过BindingBuilder.bind(queue).to(exchange)绑定的直连交换机，就会因 routingKey 不匹配导致消息丢失，且不报错——这是更隐蔽的问题
✅ 正确做法：除非你明确知道目标队列绑定的是空 routingKey（极少见），否则永远显式传入合法 routingKey，并加防御性判断：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
String rk = Optional.ofNullable(payload.getRoutingKey())
.map(String::trim)
.filter(s -> !s.isEmpty() && s.length() c >= 33 && c new IllegalArgumentException("Invalid routing key: " + payload.getRoutingKey()));
template.convertAndSend("my.direct.exchange", rk, payload);
配置类里声明 Binding 时 routingKey 写错也间接导致此错
如果你在 @Configuration 类中用 BindingBuilder.bind(queue).to(exchange).with("xxx") 声明了绑定，但运行时代码里传的 routingKey 和这里的 "xxx" 不一致（比如大小写、多空格、前后缀差异），虽然不会直接报 Invalid routing key format，但会导致消息进不了队列；而开发者为了“修复”，可能随手改成空串或乱填，反而触发该异常。
检查要点：
- 确认
Binding.with("...")的值和发送时传的routingKey字面量**完全一致**（区分大小写） - 避免在
with()里写 SpEL 或变量，它只接受静态字符串；动态路由必须靠发送端控制 - 如果要用通配符（
TopicExchange），确保routingKey符合word.word格式，不含#或*（那是 pattern，不是 key）
容易被忽略的点：测试环境 mock 导致的假象
用 @MockBean RabbitTemplate 做单元测试时，mock 行为默认不校验 routingKey，所以测试能过；但一到集成测试或真实环境，校验生效就立刻暴露问题。不要依赖 mock 掩盖格式问题。
真正要守住的底线只有一条：所有进入 convertAndSend 的 routingKey，必须在调用前完成非空、长度、字符集三重校验——这不是过度设计，是 AMQP 协议的硬性要求。
