最可靠方式是通过RabbitMQ管理插件的HTTP API查询队列状态：/api/queues/{vhost}/{queue}返回JSON中的messages（就绪消息数）和consumers字段，需URL编码vhost、Basic Auth认证并处理401/404错误。
用 HTTP API 直接查队列状态最可靠
RabbitMQ 的管理插件（rabbitmq_management）暴露了标准 HTTP 接口，/api/queues/{vhost}/{queue} 路径返回的 JSON 里就包含 messages 和 consumers 字段——这是唯一能准确获取实时 Message Count 和 Consumer Count 的方式。AMQP 协议本身不提供这类监控信息，所有“纯客户端”方案（比如用 streadway/amqp 连上去发个命令）都不行。
实操要点：
- 确保 RabbitMQ 启用了管理插件：
rabbitmq-plugins enable rabbitmq_management - vhost 名要 URL 编码，比如
/得写成%2F；队列名中若有特殊字符也需编码 - 请求需带 Basic Auth，用户名密码必须有
monitoring或management权限 - Go 中推荐用
http.Client发 GET 请求，别依赖第三方封装库——很多库对 vhost 编码或认证处理不一致
Go 里调用 API 的最小可行代码
不用额外依赖，原生 net/http 就够。重点是构造正确 URL、处理认证、解析响应字段：
func getQueueStats(host, vhost, queue, user, pass string) (int, int, error) {
encodedVHost := url.PathEscape(vhost)
urlStr := fmt.Sprintf("http://%s/api/queues/%s/%s", host, encodedVHost, queue)
req, _ := http.NewRequest("GET", urlStr, nil)
req.SetBasicAuth(user, pass)
resp, err := http.DefaultClient.Do(req)
if err != nil {
return 0, 0, err
}
defer resp.Body.Close()
var data map[string]interface{}
if err := json.NewDecoder(resp.Body).Decode(&data); err != nil {
return 0, 0, err
}
messages := int(data["messages"].(float64))
consumers := int(data["consumers"].(float64))
return messages, consumers, nil
}
注意：messages 是就绪消息数（ready），不是 total；如果需要包含未确认（unacknowledged）的消息，得看 messages_ready 和 messages_unacknowledged 字段，不能只取 messages。
立即学习“go语言免费学习笔记（深入）”；
常见错误：返回 404 或 401
这两个状态码占了调试时的八成问题：
-
404 Not Found：vhost 不存在、队列名拼错、管理插件没启用、URL 路径少写了/api/queues前缀 -
401 Unauthorized：用户没被赋予对应 vhost 的权限（用rabbitmqctl list_permissions -p {vhost}查），或密码含特殊字符但没在 Basic Auth 中正确编码 - 用 curl 先验证再写 Go：
curl -u user:pass "http://localhost:15672/api/queues/%2F/my_queue"，避免把网络或权限问题误判成 Go 代码 bug
Consumer Count 为 0 但消息堆积？那不是 Bug
consumers 字段统计的是当前活跃的 AMQP channel 级消费者数量，和你代码里启了多少个 goroutine 无关。常见误判场景：
- 消费者程序已启动但还没调用
ch.Consume()，或调用后立即 panic 退出，API 就看不到它 - 消费者设置了
autoAck = true，但处理逻辑极快，channel 快速关闭又重建，API 抓不到瞬时值 - 使用了 Prefetch Count 限制，但所有消息都被预取且未 ack，此时
consumers是 1，messages_unacknowledged却很高——得结合多个字段看，不能只盯一个数
Message Count 和 Consumer Count 都是瞬时快照，RabbitMQ 不保证强一致性。如果业务需要精确计数，得自己在生产/消费端加原子计数器，别依赖管理 API 的返回值做核心逻辑判断。
