最轻量可靠的方式是调用 rabbitadmin.getexchangenames() 获取所有 exchange 名称，它返回包含当前 rabbitmq 中所有 durable 且非 auto-delete 的 exchange 名称的 set，不触发声明动作，纯读取；若需检查 autodelete 或临时 exchange，则需手动通过 channel 调用 exchangedeclarepassive()。
直接调用 getExchangeNames() 获取所有 Exchange 名称
Spring Boot 的 RabbitAdmin 并没有提供类似 exchangeExists(String name) 的原生方法。最轻量、最可靠的方式是调用 rabbitAdmin.getExchangeNames()，它返回一个 Set<string></string>，包含当前 RabbitMQ 中所有已声明的 Exchange 名称（仅限 durable 且非 auto-delete 的 Exchange，见下文说明）。
注意：这个方法不触发任何声明动作，纯读取；但前提是 RabbitMQ 连接正常，且用户权限允许查询元数据。
- 如果目标 Exchange 是
durable=true且autoDelete=false（这是 Spring Boot 默认行为），它一定会出现在返回集合里 - 如果 Exchange 是
autoDelete=true，且当前没有任何 Queue 绑定到它，该 Exchange 可能已被 RabbitMQ 自动清理，getExchangeNames()就查不到 - 如果 Exchange 是临时的（
durable=false），RabbitMQ 重启后就消失，getExchangeNames()也不会返回它
用 declareExchange() + 异常捕获间接判断
如果你需要兼容 autoDelete=true 或临时 Exchange，或者想在“不存在时自动创建”，可以尝试调用 rabbitAdmin.declareExchange() 并捕获 AmqpConnectException 或更具体的 IOException ——但注意，这**不是判断依据**。
真正有用的异常是 org.springframework.amqp.AmqpIOException 包裹的底层 AMQP 协议错误，比如 404 NOT_FOUND（Exchange 不存在）或 406 PRECONDITION_FAILED（类型/持久化属性冲突）。不过 Spring 默认会静默忽略大部分声明失败（除非配置了 ignore-declaration-exceptions=false）。
- 默认情况下，
declareExchange()成功或失败都不会抛异常（它只做“尽力而为”声明） - 如需让它抛异常，必须显式配置：
spring.rabbitmq.template.mandatory=true不起作用；正确方式是在RabbitAdmin构造时传入ignoreDeclarationExceptions = false - 即便如此，404 错误仍可能被吞掉——RabbitMQ 协议本身对 “declare exchange” 操作不定义“检查存在”的语义，只有“声明+参数校验”
为什么不能依赖 queueDeclarePassive() 类比实现？
有人会想到 RabbitMQ 原生客户端的 channel.exchangeDeclarePassive(exchangeName)（被动声明，仅校验存在性），但 Spring AMQP **没有暴露这个能力**。它的 RabbitAdmin 所有 declare 方法都是主动式（active），且封装层级较高，无法穿透到 channel 级别做 passive 操作。
若真需要 passive 检查，只能绕过 RabbitAdmin，手动获取 Connection 和 Channel：
channel.exchangeDeclarePassive("my.exchange"); // 存在则返回，不存在抛 IOException
但要注意：
- 这个
Channel必须来自未关闭的Connection，且不能是 Spring 管理的短生命周期 channel（比如 listener 内部的） - 每次调用都是一次 AMQP 协议交互，频繁使用会影响性能
- 需自行处理连接异常、线程安全和资源释放，不适合高频探测场景
实际建议：按场景选策略，别强求“精确判断”
绝大多数 Spring Boot 场景下，Exchange 是由配置类或 @Bean 显式声明的，生命周期与应用一致。此时“判断是否存在”本身意义不大——你应该确保它被声明，而不是反复检查。
真正需要判断的典型场景只有两个：
- 运维脚本或健康检查端点中，需确认关键 Exchange 是否在线（此时用
getExchangeNames()最稳） - 多实例部署时，防止多个服务实例并发声明同一 Exchange 导致参数冲突（此时应依赖声明幂等性，而非先查后建）
记住：RabbitMQ 的 Exchange 声明本身就是幂等的——只要 name、type、durable、autoDelete、internal、arguments 完全一致，重复 declare 不会报错。所以与其花精力判断，不如确保声明逻辑只执行一次（例如放在 @PostConstruct 或 @Bean 初始化块中）。
