RabbitMQ路由配置最佳实践：路由相关实体创建方案咨询

你在Spring Boot配置类里声明Queue、Binding、DirectExchange Bean让应用启动自动创建RabbitMQ资源的方式，对个人练手项目来说完全合理，也是中小项目里非常通用的做法，没必要硬拆成启动前单独调管理API创建的流程。

• 启动时由Spring AMQP自动声明（你当前的用法）
  Spring加载到这些Bean后，会在建立RabbitMQ连接时通过AMQP协议发起资源声明请求：资源不存在就新建，已存在且参数完全匹配就直接复用，参数不匹配会直接抛启动错误。
  这种方式的优势是本地开发、测试环境可以做到拉代码直接启动，不需要额外跑初始化脚本，资源配置和业务代码放在一起，开发维护的时候不用跨地方找路由规则。
  适合个人项目、团队规模不大、业务服务独占RabbitMQ vhost、没有统一运维管控资源的场景。用的时候注意两点：一是所有持久化资源别开自动删除配置，二是生产环境给服务配的RabbitMQ账号只分配对应vhost的配置、读写权限就行，别给全局管理员权限。
• 启动前独立步骤预创建（curl调管理API/IaC工具/运维脚本提前建）
  这种方式一般是中大型团队生产环境的选择：多服务共用同一个RabbitMQ集群时，资源的创建、参数配置、权限分配统一由运维侧管控，业务服务没有创建/修改资源的权限，只能读写已经分配好的交换机和队列。
  优势是所有资源配置可审计，不会出现不同服务写的队列参数不一致导致启动失败、或者业务代码误改资源配置的问题，运维侧可以统一做容量规划、死信策略、流控规则配置。
  缺点是本地开发需要额外做资源初始化，没法一键启动，对小项目来说完全是增加不必要的流程成本。

• 不管选哪种方式，所有固定路由的交换机、队列、绑定参数必须全局统一，尤其是持久化标识、死信队列配置、消息TTL、队列最大长度这类核心参数，只要有一个客户端声明的参数和已存在资源不匹配，就会触发通道错误导致消息收发失败。
• 如果用Spring自动声明的方案，生产环境建议打开spring.rabbitmq.listener.simple.missing-queues-fatal=true配置，启动时如果资源校验、创建失败直接终止应用启动，别等上线跑业务了才发现路由不对导致消息丢了。
• 除了业务必须的临时匿名队列（比如RPC回调的临时队列），不要在业务运行过程中动态创建固定路由规则的资源，这类资源必须在应用启动阶段就完成声明校验。
• 你做个人练手项目的话，就用现在的配置类声明方式就行，等后面做多服务协作、需要统一管控集群资源的时候，再考虑把资源创建拆成独立前置步骤就好。

内容的提问来源于stack exchange，提问作者user8880523