amqp.dial连不上rabbitmq的三大原因：端口不通（检查rabbitmq是否启动及docker网络配置）、tls未正确启用（需改用amqps并传入tls配置）、连接字符串错误（如localhost在容器内指向错误）。
amqp.Dial 连不上 RabbitMQ？八成是连接字符串或网络环境没对，不是代码写错了。
连接失败的三个高频原因和对应检查项
本地开发时 amqp.Dial("amqp://guest:guest@localhost:5672/") 报 timeout 或 connection refused，先别改 Go 代码，按顺序排查：
- 用
telnet localhost 5672或nc -zv localhost 5672确认端口真通——很多情况是 RabbitMQ 没启动，或 Docker 容器没暴露5672端口 - Docker 场景下，Go 服务若也在容器里，
localhost指的是它自己，不是宿主机；得换成 RabbitMQ 容器名（如rabbitmq），并确保两者在同一个docker network中 - 启用了 TLS？必须把协议改成
amqps://，且初始化amqp.DialConfig时传入带TLSClientConfig的配置，否则 handshake 卡死无报错
消息发出去就丢？默认 publish 是“发完即忘”
channel.Publish 返回 nil ≠ 消息已进队列。网络抖动、broker 重启、信道异常关闭都会导致静默丢失。
- 启用 publisher confirms：调
channel.Confirm(false)，再用channel.NotifyPublish接收amqp.Confirmation - HTTP handler 里别阻塞等 ACK；用带缓冲的
chan amqp.Confirmation异步接收，加超时控制（比如 500ms），超时就记日志+告警 - 消息体加
delivery_mode: 2（即amqp.Publishing{DeliveryMode: amqp.Persistent}），但前提是队列声明时也设了durable: true，否则 broker 重启后队列没了，持久化消息照样丢 - 不要每次请求都
amqp.Dial+Channel()；复用全局*amqp.Connection，按业务类型（如邮件/导出/通知）建独立*amqp.Channel
消费者重复处理或崩溃退出？autoAck 和 QoS 是关键
消费者进程 panic、OOM 或被 kill 后未 ack，RabbitMQ 会重投消息——如果业务没做幂等，注册邮件发两遍就是常态。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 消费时一定设
autoAck: false，只在业务逻辑彻底执行完、无副作用后再调delivery.Ack(false) - 用
channel.Qos(1, 0, false)控制预取数量，避免一个慢任务卡住整个 channel，其他消息饿死 - 显式 recover panic，并调
delivery.Nack(false, true)（requeue=false），防止消息反复重试压垮下游 - 消费者启动时声明 queue，若之前建过
durable=false的同名队列，再以durable=true去声明会直接报ChannelError: PRECONDITION_FAILED
Web 请求里要不要等 RabbitMQ 返回结果？
不该等。异步任务的本质就是解耦。Gin handler 里调完 channel.Publish 就该立即返回 HTTP 响应。等 ACK、等消费完成、甚至等数据库落盘，都违背了异步设计初衷。
真正容易被忽略的是：shutdown 阶段怎么安全退出。必须按顺序做三件事——先关 HTTP server 拒绝新请求，再调 ch.Cancel("shutdown") 主动取消 consumer，最后等 unacked 消息收到 final ack/nack，才关 channel 和 connection。跳过这一步，正在处理的消息可能被丢弃或重复投递。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
