应明确区分grpc（同步强依赖）与rabbitmq（异步解耦）职责：grpc用于实时扣库存、生成订单等关键链路，需超时控制与轻量handler；rabbitmq用于通知积分、短信等后续动作，需幂等设计、死信处理与独立连接管理。
不能直接用 gRPC 调用 RabbitMQ，也不能把 RabbitMQ 当成 gRPC 的传输层来用——它们解决的是不同层面的问题。 你真正需要的，是明确哪些通信走同步（gRPC），哪些走异步（RabbitMQ），并在 Go 微服务中各自落地、互不干扰地协作。
gRPC 用于核心业务链路的强依赖调用
比如用户下单后，必须实时扣减库存、生成订单号、更新账户余额——这些环节有严格时序和结果依赖，适合用 gRPC 同步调用。Go 服务之间通过 protoc 生成的客户端/服务端代码通信，基于 HTTP/2 和 Protocol Buffers，延迟低、类型安全。
- 务必为每个 gRPC 客户端配置
context.WithTimeout，避免一个慢请求拖垮整个链路 - 不要在 gRPC handler 里做耗时操作（如发邮件、写日志到磁盘），应转成消息投递到 RabbitMQ
- gRPC Server 不要直接依赖
amqp.Connection，保持协议层与业务逻辑分离
RabbitMQ 用于非关键、可重试、需解耦的后续动作
例如“订单创建成功”这个事件，需要通知积分服务、发送短信、触发风控分析——这些不阻塞主流程，且允许短暂延迟或失败重试，就该交给 RabbitMQ。
- 使用
fanoutexchange 实现事件广播：一个事件发出去，多个消费者（积分、短信、风控）各自消费 - 消费者用独立的 Go 程序或 goroutine 启动，与 gRPC 服务进程隔离，避免相互影响
- 消息体建议用 JSON 或 Protobuf 序列化，但别复用 gRPC 的
.protoservice 定义——只复用 message 定义即可
连接管理与错误隔离必须分开做
gRPC 和 RabbitMQ 的连接生命周期完全不同：gRPC 连接应长期复用（用 grpc.WithTransportCredentials + 连接池），而 RabbitMQ 的 amqp.Connection 需要主动心跳检测和自动重连。
- 不要共用同一个
context.Context控制 gRPC 调用和 RabbitMQ 发送——前者超时要快（500ms），后者可设为30s - RabbitMQ 生产者失败时，不要 panic 或直接返回 gRPC 错误；应记录告警 + 本地重试（最多 3 次），失败则落库待补偿
- 消费者处理失败时，用
ch.Nack()带requeue=false进入死信队列，而不是无限重试导致堆积
最容易被忽略的是消息幂等性设计：gRPC 接口天然支持重试，但 RabbitMQ 消息可能重复投递。消费者必须根据消息里的 event_id 或业务单号做去重，而不是依赖“RabbitMQ 只发一次”这种错误假设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
