grpc是go微服务间调用最稳妥方案，因其类型安全、高性能和协议一致性；http/json仅适用于对外暴露或临时桥接，内部调用应避免。
用 gRPC 实现 Go 微服务间调用最稳妥
Go 生态里，gRPC 是跨服务调用的默认选择，不是因为它最简单，而是它在类型安全、性能、协议一致性上几乎没有替代方案。HTTP/JSON 虽然易调试，但字段错位、类型丢失、无契约约束，上线后容易因结构变更引发静默失败。
实操建议：
- 所有服务共用一个
api/目录存放.proto文件，由 CI 自动生成 Go stub（protoc --go_out=. --go-grpc_out=. *.proto） - 服务端必须显式设置
grpc.KeepaliveParams，否则长连接在 Kubernetes 的 Service Mesh（如 Istio）下容易被中间件断连 - 客户端不要复用
grpc.Dial返回的*grpc.ClientConn跨 goroutine 写入；应封装为单例或通过依赖注入传递，避免context canceled泛滥 - 错误码统一用
status.Errorf(code, msg)构造，禁止直接返回errors.New—— 否则下游无法用status.Code(err)解析
HTTP 调用只适合对外暴露或临时桥接
Go 里用 http.Client 调第三方 API 或旧系统是合理的，但两个内部微服务之间走 HTTP/JSON，等于主动放弃编译期校验和流控能力。常见问题包括：字段名大小写不一致导致反序列化为零值、int64 超出 JavaScript 安全整数范围、无超时导致 goroutine 泄漏。
如果非用不可，注意：
