ch.assertQueue 是声明式操作，确保队列按预期配置存在并校验一致性；ch.checkQueue 仅只读检查存在性，不创建、不校验、不修改状态。
ch.assertQueue 和 ch.checkQueue 的本质区别
两者根本不是性能对比关系，而是语义和用途完全不同：ch.assertQueue 是声明式操作（声明“我要这个队列”，不存在就创建，存在就校验配置是否一致）；ch.checkQueue 是只读探针（仅检查队列是否存在，不创建、不校验参数、不修改 Broker 状态）。生产环境里误用 ch.checkQueue 替代 ch.assertQueue，会导致队列未创建就发消息，直接抛出 NOT_FOUND 错误。
为什么生产环境必须用 ch.assertQueue
ch.assertQueue 能确保队列按预期配置存在，尤其关键参数如 durable: true、autoDelete: false、arguments（比如 x-dead-letter-exchange）都会被 Broker 校验。若已有同名队列但配置不一致（例如旧队列是 durable: false，新代码要求 true），Broker 会明确返回 PRECONDITION_FAILED 错误，而不是静默忽略——这正是你发现配置漂移的唯一机会。
- 不调用
ch.assertQueue就直接sendToQueue，RabbitMQ 会拒绝投递并抛NOT_FOUND - 用
ch.checkQueue得到 “存在” 结果后仍需再调ch.assertQueue才能安全发消息，纯属多一次 RPC - CI/CD 部署时，
assertQueue是幂等的，可放心放在启动脚本里，而checkQueue没有部署价值
ch.assertQueue 的性能开销其实可以忽略
它底层是一次 AMQP Queue.Declare 方法调用，耗时约 0.5–2ms（本地网络），远低于 TCP 建连、SSL 握手或消息序列化本身。真正影响性能的是错误用法：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 在每次发消息前都调一次
ch.assertQueue—— 应该只在应用初始化时调用一次 - 对同一队列反复声明（比如每秒调 100 次），会触发 RabbitMQ 内部元数据锁争用
- 传入不一致的
arguments导致频繁PRECONDITION_FAILED，说明配置管理混乱，这不是库的问题
容易被忽略的细节：durable 和 autoDelete 组合陷阱
生产环境最常踩的坑是以为设了 durable: true 就万事大吉，却忽略了 autoDelete: true 会覆盖它——只要最后一个消费者断开，队列立刻销毁，哪怕它是持久化的。正确写法必须显式写全：
await ch.assertQueue('task_queue', {
durable: true,
exclusive: false,
autoDelete: false
});
这个组合才是真正的“生产就绪队列”。漏掉 autoDelete: false，重启消费者进程后队列消失，消息全丢，而日志里可能只有一行模糊的 CHANNEL_ERROR。
