gRPC是内网高并发低延迟场景的首选，但需复用ClientConn、启用HTTP/2、正确配置超时与服务发现；HTTP/JSON适用于对外API；消息队列需保障可靠性与幂等性。
gRPC 是内网服务通信的默认选择，但别急着写 grpc.Dial
Go 微服务跑在内网、高并发、低延迟要求下，gRPC 几乎是唯一合理选项：HTTP/2 多路复用避免队头阻塞，Protobuf 序列化体积只有 JSON 的约 35%，实测 QPS 提升 3–5 倍，延迟降 40%~60%。但性能优势不会自动生效——grpc.Dial 每次调用都含 DNS 解析、TLS 握手、HTTP/2 协商，开销远超一次 RPC 调用本身。
- 必须复用
*grpc.ClientConn，全局单例或连接池管理，禁止在 handler 里反复grpc.Dial - 服务端监听要明确启用 HTTP/2：
grpc.NewServer()后直接srv.Serve(lis)，不要混用http.Server代理 - 若前端 Nginx 反向代理 gRPC，必须配置
http2和grpc_pass，否则降级成 HTTP/1.1，多路复用失效 - 客户端超时由
context.WithTimeout控制，但别在服务端 handler 里重设 deadline——会截断上游剩余时间，引发雪崩式重试
HTTP/JSON 不该被抛弃，而是用在它该在的地方
HTTP 不是“过时协议”，它是对外暴露 API 的事实标准：浏览器、App、第三方系统无法直接消费 gRPC 二进制流；Kong、AWS API Gateway、CDN 等中间件只认 Authorization、Cache-Control 等标准头部；curl -X POST http://localhost:8080/api/user 一行就能验证接口，而 grpcurl 需要额外证书和 proto 文件。
- 内部服务间慎用
net/http同步调用——默认无超时，http.Client不设Timeout和Transport参数，生产环境极易拖垮整条链路 - 务必显式配置：
Timeout（建议 ≤ 3s）、MaxIdleConns（≥ 100）、IdleConnTimeout（≤ 30s） - 错误需分层处理：
url.Error是网络层失败，resp.StatusCode >= 400是业务层错误，不能只看err != nil - 大响应体必须手动调用
resp.Body.Close()，否则连接泄漏，MaxIdleConnsPerHost很快耗尽
消息队列不是“加个 Kafka 就完事”，可靠性取决于你怎么用
当订单创建后要通知库存、发短信、写日志，这些不需要即时响应的操作，就该交给 Kafka、RabbitMQ 或 NATS。但异步不等于“随便发”，消息可能重复、丢失、乱序——你得主动设计保障机制。
- Kafka 生产者必须设
RequiredAcks: kafka.RequireAllIsr+MaxRetries: 3，否则网络抖动就丢消息 - NATS Streaming 客户端
ClientID必须全局唯一（比如用 Pod ID），否则旧连接会被踢出，消息中断 - 消费者处理失败时，不能简单
log.Fatal——要重试 + 死信队列（DLQ），把反复失败的消息隔离出来人工介入 - 所有消费者逻辑必须幂等：同一条
OrderCreated消息被投递两次，库存扣减结果也得和一次一样
别忽略服务发现和连接生命周期，它们决定你能跑多久
硬编码 "127.0.0.1:50051" 在开发期没问题，上线后服务实例动态伸缩，没服务发现就是定时炸弹。gRPC 原生支持自定义解析器，但多数团队卡在“怎么跟 Consul / etcd 对接”这一步。
立即学习“go语言免费学习笔记（深入）”；
- gRPC 客户端可传入
grpc.WithResolvers()，自己实现resolver.Builder查询注册中心获取实例列表 - HTTP 客户端更简单：封装一个
ServiceClient结构体，每次请求前调用GetEndpoints("user-service")拿可用地址，配合轮询或一致性哈希负载均衡 - 无论 HTTP 还是 gRPC，都要监控连接状态：
transport is closing错误通常不是代码问题，而是空闲连接被防火墙或 LB 中断——必须配keepalive.EnforcementPolicy主动心跳保活
真正难的从来不是选协议，而是把连接复用、超时传递、错误分层、幂等设计这些细节嵌进每一行调用里。漏掉任何一个，压测时都可能突然崩掉。
