连不上 RabbitMQ 主因是 URL 格式错误或网络隔离：Docker 中需用容器名代替 localhost、暴露 5672 端口、TLS 时改用 amqps:// 并配 TLSClientConfig。
为什么 amqp.Dial 连不上 RabbitMQ？
本地开发时连不上，八成是 URL 格式或网络隔离问题。RabbitMQ 默认不监听外部 IP，Docker 容器没暴露 5672 端口，或者用了 localhost 却在容器里跑 Go 程序——这时 localhost 指的是容器自己，不是宿主机。
- 检查连接字符串是否带协议和端口：
"amqp://guest:guest@localhost:5672/"，不能漏掉:5672 - Docker 场景下，Go 服务若也在容器中，把
localhost换成 RabbitMQ 容器名（如rabbitmq），并确保在同一 network 中 - 用
telnet localhost 5672或nc -zv localhost 5672先确认端口可达，比看 Go 报错快得多 - 如果启用了 TLS，必须用
amqps://，且客户端要配置amqp.Config{TLSClientConfig: ...}，否则会卡在 handshake 阶段
怎么安全地发消息而不丢任务？
Web 请求里调 channel.Publish 后就返回成功，但 RabbitMQ 可能根本没收到——默认是“发完即忘”，网络抖动、broker 重启、信道关闭都会导致消息丢失。
- 启用 publisher confirms：
channel.Confirm(false)，再用channel.Publish+channel.NotifyPublish监听 ACK/NACK - 不要在 HTTP handler 里直接阻塞等 ACK；改用带缓冲的 channel 接收确认结果，超时则记日志+告警，避免拖慢接口
- 消息体建议加
delivery_mode: 2（持久化），但注意：队列本身也得声明为 durable，否则 broker 重启后队列消失，持久化消息照样丢 - 别在每次请求都新建 connection/channel；复用 connection，按业务边界（比如每种任务类型）建独立 channel
消费者怎么避免重复处理或崩溃退出？
HTTP handler 发完消息就结束，但消费者进程挂了、OOM、panic 或手动 kill，没来得及 ack，RabbitMQ 就会把消息重投——没做幂等，用户注册发了两次邮件很常见。
- 消费时设
autoAck = false，只在业务逻辑彻底执行完、无副作用后再调delivery.Ack(false) - 用
channel.Qos(1, 0, false)限制预取数量，防止一个慢任务堵住整个 channel，其他消息饿死 - 捕获 panic 并显式
delivery.Nack(false, true)（requeue=false），避免消息反复重试压垮下游 - 消费者启动时声明 queue 和 exchange，但不要设
durable=true后又改durable=false；已存在的非 durable 队列无法被覆盖，会报ChannelError: PRECONDITION_FAILED
Web 请求里要不要等 RabbitMQ 返回结果？
不该等。异步任务的本质就是解耦响应时间和后台处理时间。同步等 ACK 已经是底线，再等消费完成，就退化成 RPC 了，还丢了 RabbitMQ 的缓冲和削峰能力。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 接口只负责“接收请求 → 校验 → 发消息 → 返回 202 Accepted”，Body 可带 task_id 方便前端轮询
- 真需要结果，另起一个轻量 endpoint 查状态（比如查 Redis 里的 task_id → result），而不是让生产者阻塞订阅 reply-to 队列
- 如果业务强依赖执行结果（如支付回调验证），说明这不是异步任务场景，该走同步 HTTP 调用或数据库状态机驱动
- 注意 context 传递：handler 的
ctx别直接传给amqp.Publish，它不支持 cancel；超时控制放在上层，比如用context.WithTimeout包一层 publisher 逻辑
最麻烦的永远不是连上 RabbitMQ，而是消息语义没对齐：你当它可靠，它其实在尽力而为；你当它异步，又忍不住想等结果。边界划清楚，比调对某个函数重要得多。
