amqp.Dial() 连接失败主因是环境或URI配置错误：localhost在容器中需换宿主机IP或Docker别名；guest账号默认禁远程，须创建用户并赋权；vhost须预先存在；心跳超时可调为heartbeat=30。
amqp.Dial() 连接失败的常见原因和验证方式
连不上 RabbitMQ，八成不是代码写错，而是环境或 URI 配置不对。amqp.Dial() 看似简单，但一旦报错如 dial tcp 127.0.0.1:5672: connect: connection refused 或 authentication failure，就得逐层排查：
-
amqp://guest:guest@localhost:5672/中的localhost在容器或远程部署时很可能不生效——换成宿主机 IP（如10.225.7.138）或 Docker 网络别名 - 默认
guest/guest账号在 RabbitMQ 3.3+ 版本后禁止远程登录，必须显式创建用户并赋权：rabbitmqctl add_user app_user app_password+rabbitmqctl set_permissions -p / app_user ".*" ".*" ".*" - URI 末尾的 vhost（如
/myvhost）若未创建，Dial()不报错，但后续Channel()或声明操作会失败，建议先用rabbitmqctl list_vhosts确认 - 心跳超时默认 10 秒，高延迟网络下可能触发连接中断，可加参数：
amqp://...?heartbeat=30
ch.Publish() 发不出消息？检查这四个参数组合
消息“发了但收不到”，往往卡在交换器（exchange）、路由键（routing key）、队列（queue）三者绑定关系上。最简场景（无 exchange）下，ch.Publish() 的前两个参数必须匹配：
- 第一个参数
exchange传空字符串""→ 表示使用默认 direct 类型的 AMQP 内置 exchange - 第二个参数
routingKey必须与QueueDeclare("hello", ...)声明的队列名完全一致（此时默认绑定生效） - 若用了自定义 exchange（如
"my_exchange"），则必须配套调用ch.QueueBind()，否则消息被丢弃且无提示 -
mandatory设为true时，若无队列匹配该 routing key，会返回NO_ROUTE错误；设false（默认）则静默丢弃——调试期建议设true暴露问题
amqp091-go 和 streadway/amqp 选哪个？兼容性差异很实际
你看到的教程里混用两种库，不是作者懒，是 Go 生态真实存在的割裂：github.com/rabbitmq/amqp091-go 是 RabbitMQ 官方维护的新库（2022 年起），而 github.com/streadway/amqp 是社区长期使用的旧版。关键区别：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
amqp091-go支持 context（如ch.PublishWithContext(ctx, ...)），能控制超时和取消；streadway/amqp所有方法都无 context，超时需靠连接层或手动 goroutine 控制 -
amqp091-go的QueueDeclare默认durable=false，重启 RabbitMQ 后队列消失；旧库同名参数行为一致，但文档更模糊 - 两者 API 高度相似，但类型不兼容——不能把
amqp091-go.Channel当作streadway/amqp.Channel传参 - 新项目优先用
amqp091-go；老项目升级需注意DeliveryMode、ContentEncoding等字段位置微调
为什么消息发出去了却没被消费？消费者端常漏的关键步骤
生产者跑通 ≠ 端到端可用。消费者侧最容易忽略的是：队列必须存在、必须有 active consumer、且 channel 不能提前关闭。
立即学习“go语言免费学习笔记（深入）”；
- 消费者启动时，应主动
ch.QueueDeclare("hello", true, false, false, false, nil)—— 即使生产者已声明，也要确保 durable 属性一致，否则 RabbitMQ 视为不同队列 - 调用
ch.Consume()后，必须持续从返回的<-amqp.Delivery通道读取，否则消息堆积在 prefetch 缓冲区，RabbitMQ 认为 consumer “忙”而不派发新消息 - 没有
ch.Qos(1, 0, false)限流时，RabbitMQ 可能批量推送多条消息，若 consumer panic 或 exit，未 ack 的消息会重回队列（取决于autoAck设置） - consumer 进程退出前，务必调用
ch.Cancel()或让conn.Close()触发 clean shutdown，否则 RabbitMQ 仍认为该 consumer 在线，不再分发消息
真正麻烦的从来不是写几行 publish 代码，而是确认 exchange/type/bindings 是否对得上、vhost 权限是否开全、consumer 是否真的在 running 状态——这些没法靠编译器报错提醒，只能靠 rabbitmqctl list_exchanges、list_bindings、list_queues 一条条核对。
