因为@bean在容器启动时即完成声明，无法按需动态增删；真正动态创建须用amqpadmin手动调用declarequeue()等方法，且需确保队列名合法、参数类型匹配、声明顺序正确（exchange→queue→binding）。
为什么不能直接用 @Bean 定义动态队列？
因为 @Bean 方法在 Spring 容器启动时就执行完毕，所有 Queue、Exchange、Binding 实例被提前注册进 AmqpAdmin，后续无法按需增删。真正动态创建必须绕过声明周期管理，改用 AmqpAdmin 手动调用 declareQueue()、declareExchange()、declareBinding()。
怎么用 AmqpAdmin 创建带参数的 Queue？
关键点是：队列名必须唯一；durable、exclusive、autoDelete 要和实际业务语义匹配；额外参数（如 x-message-ttl）必须通过 Map 传入，且 key 是字符串，value 类型要与 RabbitMQ 协议一致（比如 Long，不是 Integer）。
常见错误现象：ChannelShutdownException 或后台报 “queue.declare: queue name is empty”，通常是因为传了 null 队列名或未检查 AmqpAdmin 是否已初始化。
-
AmqpAdmin默认不自动注入，需确保 Bean 可获取（例如加@Autowired或用ApplicationContext.getBean(AmqpAdmin.class)） - 队列名建议做合法性校验（只含字母、数字、下划线、点、破折号，长度 ≤ 255）
- 若需设置 TTL，用
Map.of("x-message-ttl", 60000L)，注意L后缀 - 避免重复 declare 同名队列——RabbitMQ 会校验参数一致性，不一致则抛
IOException
Exchange 和 Binding 怎么配才不会 404？
Binding 失败最常见的原因是 exchange 或 queue 尚未存在，或类型不匹配（比如向 fanout exchange bind 时还传了 routingKey）。必须严格遵循声明顺序：先 declareExchange()，再 declareQueue()，最后 declareBinding()。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
使用场景举例：多租户系统中为每个租户创建独立 topic exchange + queue + binding，routingKey 按租户前缀隔离（如 tenant-a.#）。
-
DirectExchange和TopicExchange的declareExchange()必须设durable=true（否则 binding 时可能被拒绝） -
BindingBuilder.bind(queue).to(exchange)是声明式写法，但底层仍走AmqpAdmin；动态场景下推荐直接用amqpAdmin.declareBinding(new Binding(...))，控制更明确 - binding 的
routingKey为空字符串对fanout有效，但对direct无效——此时必须显式指定非空 key
删除操作有哪些隐藏风险？
调用 amqpAdmin.deleteQueue("my_queue") 看似简单，但 RabbitMQ 不会立即释放资源：如果还有消费者正在消费，队列会延迟删除；如果绑定了 exchange，binding 会被自动清理，但 exchange 本身不会被删（RabbitMQ 不支持 cascade delete）。
更麻烦的是：Spring Boot 的 SimpleMessageListenerContainer 默认会监听已声明的队列，如果队列被外部删掉，容器会不断重连并打印 WARN 日志（Consumer raised exception, processing can restart if the connection factory supports it）。
- 删除前务必停掉对应消费者的
MessageListenerContainer（调用stop()），否则可能触发异常重试风暴 - 不要依赖
deleteExchange()清理——它只删 exchange 元数据，不删绑定，也不删队列；真正清理需手动删 binding + queue + exchange - 生产环境慎用 delete 操作，建议用 TTL + auto-delete 队列替代“动态生命周期”需求
declareXXX() 都走 AMQP 协议发指令，失败时不会回滚前面的操作。所以组合操作（比如建 exchange+queue+binding）必须自己实现幂等和状态检查，不能只靠 try-catch。
