消费者收不到消息主因是go-micro默认用内存注册中心导致服务发现失败，需显式配置etcd/consul；exchange类型不匹配、未调用service.Server().Start()、AMQP连接未设heartbeat及QoS控制不当亦为关键因素。
用 go-micro 连 RabbitMQ 时，为什么消费者收不到消息？
多数人卡在连接后消息“发出去了但没人处理”，核心原因是 go-micro 默认使用内存注册中心（micro.NewService 不显式配置时），服务发现失败导致消费者无法被路由到。RabbitMQ 本身只是消息中转，不负责服务发现。
- 必须显式配置注册中心，比如用
registry.NewRegistry接入etcd或consul，否则go-micro的broker层无法协同服务上下线 - RabbitMQ 的
exchange类型要和消费者声明一致：默认是topic，如果服务端用fanout发布，消费者却按topic绑定，消息就丢弃了 - 消费者启动后需调用
service.Server().Start()，否则监听逻辑没真正跑起来——这个步骤常被忽略，日志里也无报错
不用框架，纯 streadway/amqp 实现可靠消费的关键点
跳过 go-micro 直接对接 AMQP 协议更可控，但也更易出错。重点不是连上，而是扛住网络抖动、消息重复、进程崩溃这三类真实故障。
- 连接层必须启用
amqp.DialConfig中的Heartbeat（建议设为30 * time.Second），否则 RabbitMQ 会因 TCP 空闲断开连接，而 Go 客户端不自动重连 - 消费时用
channel.Qos(1, 0, false)控制预取数，避免单个消费者积压太多未确认消息，导致其他实例饿死 -
msg.Ack(false)必须在业务逻辑成功执行后才调用；若中间 panic 或 return，要确保msg.Nack(false, true)回退并重新入队，否则消息永久丢失
context.Context 在消息处理中怎么用才不踩坑？
微服务场景下，消息处理常需要超时控制、取消传播、跨协程透传，但直接把 context.Background() 传进 amqp.Consume 回调是无效的——那个 context 和消费循环无关。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个
delivery消息应生成独立子 context：ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，并在 defer 里cancel() - 若业务逻辑涉及 HTTP 调用或数据库操作，必须把该
ctx显式传给http.NewRequestWithContext或db.QueryContext，否则超时不会中断下游 - 不要在 consumer goroutine 里用
context.WithCancel向上层传递取消信号——AMQP channel 是复用的，取消会影响后续所有消息
如何让消息体结构变更不影响老消费者？
上线新字段、删字段、改类型，老版本服务一解析就 panic。Protobuf 虽好，但 Go 里更轻量的做法是用 json.RawMessage 延迟解析。
立即学习“go语言免费学习笔记（深入）”；
- 定义结构体时，把不确定的字段设为
json.RawMessage类型，比如Data json.RawMessage `json:"data"`，先校验必填字段是否存在再解码 - 用
json.Unmarshal的DisallowUnknownFields选项做兼容性兜底，但注意它只对顶层生效，嵌套对象需手动检查 - 生产者发消息前加
version字段（如"v2"），消费者根据 version 分支处理，比强依赖 schema 更灵活
消息队列不是“发完就完”，关键在消费者能否稳定、可回溯、可演进地处理每一条数据。很多问题表面是 RabbitMQ 配置，根子在 Go 的并发模型和 context 生命周期没对齐。
