必须先用 rabbitmqctl list_queues name | grep '^myapp.v1.' 确认匹配队列，再逐个删除；因无原生批量命令，需 shell 循环或 HTTP API 配合 jq 实现可控清理，且删除前须检查绑定、消息状态与持久化影响。
用 rabbitmqctl list_queues 查看并筛选队列名
批量删除前必须先确认哪些队列匹配前缀，rabbitmqctl list_queues 是最直接的手段。它默认只输出队列名和消息数两列，适合配合 grep 过滤：
rabbitmqctl list_queues name | grep '^myapp\.v1\.'
注意点：
- 正则需用单引号避免 shell 展开，点号
.要转义成\. - 如果队列名含空格或特殊字符（如
@、%），name列仍能安全输出，但后续传给delete时需确保不被截断 - 该命令默认连接本地节点；远程操作需加
-n指定节点名，或用--host+--port+--user+--password
用 rabbitmqctl delete_queue 删除单个队列（必须逐个调用）
rabbitmqctl 没有原生批量删除命令，delete_queue 只接受一个 queue_name 参数，且不支持通配符。所以得靠 shell 循环驱动：
rabbitmqctl list_queues name | grep '^myapp\.v1\.' | while read -r queue; do rabbitmqctl delete_queue "$queue"; done
关键细节：
-
read -r防止反斜杠被误处理，"$queue"加双引号避免含空格队列名出错 - 每删一个队列都会打印类似
Deleting queue 'myapp.v1.task.123' ...的日志，失败时会报错（如ERROR: queue_not_found），但不会中断整个循环 - 若队列正在被消费者使用，
delete_queue仍会成功（RabbitMQ 允许强制删除），但可能引发客户端channel error
用 HTTP API 实现更可控的批量删除（推荐用于脚本化）
如果已启用 rabbitmq_management 插件，用 REST API 更灵活，可精确控制状态检查和错误处理：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
curl -u admin:pass -X GET http://localhost:15672/api/queues | jq -r '.[] | select(.name | startswith("myapp.v1.")) | .name'
再配合 curl -X DELETE 逐个清理：
curl -u admin:pass -X GET http://localhost:15672/api/queues | jq -r '.[] | select(.name | startswith("myapp.v1.")) | .name' | while read -r q; do curl -u admin:pass -X DELETE "http://localhost:15672/api/queues/%2F/$q"; done
注意点：
-
%2F是 vhost/的 URL 编码，若用非默认 vhost（如myvhost），要替换成myvhost - API 返回 JSON，
jq是最轻量的解析工具；没装jq的话，可用python -m json.tool或grep -o替代，但可靠性下降 - HTTP API 会返回
204 No Content成功，404表示队列不存在，401表示认证失败——比rabbitmqctl更易捕获异常
删除前务必确认队列是否可删，尤其在生产环境
队列名匹配前缀不等于可以随意删。以下情况会出问题：
- 队列绑定了关键 exchange，删了会导致消息无法路由（即使没消费者，绑定关系仍在）
- 队列设置了
durable=true且有持久化消息，删掉后消息永久丢失 - 队列被镜像到其他节点，
delete_queue会同步清除所有副本，但若网络分区中执行，可能残留孤立副本 - 某些 SDK（如 Spring AMQP）会在启动时自动声明队列，删完后服务重启又重建，形成“删了又来”的假象
真正安全的做法是：先查 list_bindings 看绑定关系，再用 list_queues 看 messages_ready 和 messages_unacknowledged 是否为 0，最后才动手。自动化脚本里漏掉这步，最容易在凌晨三点收到告警。
