RabbitMQ连接易卡在dial或报io timeout，主因是网络不通（如Docker用127.0.0.1而非服务名、K8s未用Service名）或连接参数错误（vhost缺失、格式不规范），需用telnet/nc验证连通性并显式设超时。
为什么 RabbitMQ 连接容易卡在 dial 或报 io timeout
Go 微服务启动时连不上 RabbitMQ，90% 是网络或连接参数问题，不是代码写错。RabbitMQ 默认只监听 localhost，Docker 部署时若用 docker-compose，服务间必须用服务名（如 rabbitmq）而非 127.0.0.1；K8s 环境则要用 Service 名 + 正确端口（5672）。连接字符串格式必须严格：amqp://user:pass@host:port/vhost，漏掉 vhost（默认是 /）会导致认证失败但错误提示模糊。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
telnet rabbitmq 5672或nc -zv rabbitmq 5672确认基础连通性 - 连接时显式设置超时：
amqp.DialConfig{Dial: &net.Dialer{Timeout: 5 * time.Second}} - 避免在
init()中建立连接——微服务应延迟到main()启动后、健康检查就绪前再初始化
如何让 channel.Publish 不丢消息
channel.Publish 默认是异步发送，不保证投递成功。如果 RabbitMQ 拒绝（比如队列满、权限不足），Go 客户端不会 panic，也不会返回 error，而是静默失败。真正可靠的方式是启用 Publisher Confirms，并配合 notifyPublish 监听确认。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 创建 channel 后立刻调用
ch.Confirm(false)开启确认模式 - 用
ch.NotifyPublish()接收amqp.Confirmation，检查Ack字段是否为true - 不要对每条消息都阻塞等待确认——批量发完再统一处理结果，否则吞吐暴跌
- 若业务允许少量丢失，可改用
mandatory=true+notifyReturn捕获被退回的消息
消费者怎么避免重复消费和消息堆积
RabbitMQ 的 autoAck=true 是最大陷阱：消息一送达就自动标记为已处理，哪怕你的 handler panic 或进程崩溃，消息也永远消失了。正确做法是关掉 autoAck，手动 msg.Ack()，且必须在业务逻辑**完全执行成功后**才调用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 声明 consumer 时设
autoAck=false，并设置prefetchCount=1控制并发量（防 OOM） - handler 函数里用
defer msg.Nack(false, false)做兜底，再用recover()捕获 panic - 消息体建议带
message-id和timestamp，下游做幂等（例如 RedisSETNX key ttl） - 监控
queue_declare返回的Queue结构中Messages字段，持续 > 1k 就该告警扩容消费者
微服务重启时如何安全关闭 RabbitMQ 连接
直接 kill 进程会导致未确认消息丢失、channel 卡死、甚至 RabbitMQ 端留下大量 unconfirmed connection。Go 里没有“优雅关闭”的内置机制，必须自己实现信号监听 + 超时退出。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
signal.Notify监听os.Interrupt和syscall.SIGTERM - 收到信号后，先停新消息接收（关闭 consumer channel），再等正在处理的消息完成（用
sync.WaitGroup计数） - 最后按顺序关闭：
msg.Ack()→ch.Close()→conn.Close()，每个操作加 5s 超时 - 别依赖
defer关连接——它只在 goroutine 退出时触发，主进程退出时可能来不及执行
最常被忽略的是：RabbitMQ 的 connection 和 channel 都不是线程安全的，多个 goroutine 共享一个 *amqp.Connection 必须加锁，或者干脆每个 worker goroutine 持有独立连接——后者更简单、更可靠。
