gRPC 与 RabbitMQ 在 Go 微服务中必须分进程、分职责、分连接共存，禁止共享 goroutine 池、context 或连接对象；生产者发消息需 fire-and-forget，消费者须独立部署并实现幂等。
gRPC 和 RabbitMQ 在 Go 微服务中必须分进程、分职责、分连接地共存，不能共享 goroutine 池、不共用 context、不复用同一套连接对象——混用不是为了“凑齐技术栈”，而是为让同步链路不被异步动作拖垮。
gRPC handler 里发 RabbitMQ 消息的正确姿势
核心原则：发消息是 fire-and-forget，失败不阻塞主流程，也不 panic。
-
amqp.Publishing的Body推荐用 JSON（非 Protobuf），避免与 gRPC 的.proto文件耦合；若复用 message 定义，只取message块，不带service - 发送前务必设置
mandatory=true+immediate=false，配合生产者确认（channel.Confirm()）捕获路由失败 - 不要在 gRPC handler 中调用
ch.Publish()后立即ch.Wait()—— 这会把异步操作变成同步等待，违背设计初衷 - 示例中应忽略发送失败，仅记录告警：
log.Warn("failed to publish order.created", zap.Error(err))，而非return err
RabbitMQ 消费者不能和 gRPC 服务跑在同一进程里
常见错误是把 amqp.Connection 和 grpc.Server 都塞进 main()，结果一个消费者卡死导致整个 gRPC 服务 goroutine 被占满。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 消费者必须独立启动：用单独的
go run consumer/main.go或容器部署，与 gRPC 服务隔离 - 每个消费者应使用专属
ConsumerGroup（RabbitMQ 中对应 unique queue name），避免多个实例争抢同一条消息 - 不要用
channel.Qos(1, 0, false)无脑限流——它限制的是未 ack 消息数，若处理逻辑卡住，会直接堵死队列 - 消费者内部必须实现幂等：靠消息体中的
event_id或业务单号（如order_id）查本地表或 Redis 去重，而不是信任 “RabbitMQ 不会重复投递”
连接管理必须分开配置、分开超时、分开重连
gRPC 连接池和 AMQP 连接生命周期完全不同，混用会导致连接泄漏或静默断连。
- gRPC 客户端推荐用
grpc.WithTransportCredentials+grpc.WithBlock()（仅初始化时），后续调用走默认连接池；超时统一用context.WithTimeout(ctx, 500 * time.Millisecond) - RabbitMQ 生产者连接需手动心跳：
amqp.Config{Heartbeat: 10 * time.Second}，并监听notifyClose通道做自动重连 - 绝对不要用同一个
context.Context控制 gRPC 调用和 RabbitMQ 发送——前者要快，后者可容忍 30 秒级延迟 - AMQP 的
amqp.Connection不是线程安全的，每个 goroutine 应从连接池获取独立amqp.Channel，别全局复用 channel 实例
最容易被跳过的其实是错误分类：gRPC 的 rpc error: code = Unavailable desc = connection closed 和 RabbitMQ 的 amqp.ErrClosed 看似都是“连不上”，但前者大概率是服务发现失效或 TLS 握手失败，后者往往是 broker 重启或网络策略变更——它们的恢复路径和监控指标完全不一样，不能共用一套告警规则。
