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 泄漏。
如果非用不可，注意：
立即学习“go语言免费学习笔记（深入）”；
【极品模板】出品的一款功能强大、安全性高、调用简单、扩展灵活的响应式多语言企业网站管理系统。 产品主要功能如下： 01、支持多语言扩展（独立内容表，可一键复制中文版数据） 02、支持一键修改后台路径； 03、杜绝常见弱口令，内置多种参数过滤、有效防范常见XSS； 04、支持文件分片上传功能，实现大文件轻松上传； 05、支持一键获取微信公众号文章（保存文章的图片到本地服务器）； 06、支持一键
- 始终设置
http.Client.Timeout，且不超过上游 context 的 deadline；推荐用http.DefaultClient改写为带 timeout 的实例，而非每次 new - 用
jsoniter.ConfigCompatibleWithStandardLibrary替代标准encoding/json，它对空字符串转 struct 字段、NaN 处理更鲁棒 - 禁止在请求体里传原始
map[string]interface{}—— 类型信息丢失，下游无法做字段级验证；应定义明确 struct 并导出字段 - 若需兼容 OpenAPI，用
oapi-codegen从openapi.yaml生成 client，别手写http.NewRequest
Context 传递必须贯穿整个调用链
跨服务调用不是发个请求就完事。没有 context.Context 透传，你就拿不到 traceID、无法控制超时、不能取消下游请求。很多团队在 gateway 层加了 X-Request-ID，却没把该 ID 注入到下游 gRPC 的 metadata 里，结果链路追踪断在第一个跳转点。
关键动作：
- 服务入口（HTTP handler / gRPC server）用
req.Context()拿到原始 context，再通过metadata.AppendToOutgoingContext注入 traceID、user_id 等必要字段 - 下游 client 调用前，必须用
metadata.FromIncomingContext提取并透传，不能只传一次就丢弃 - 避免在中间层新建
context.Background()—— 这会导致超时失效、cancel 信号中断、logrus/zap 的 field 丢失 - gRPC metadata 的 key 必须小写加短横线（如
trace-id），大写或下划线会被底层 HTTP/2 过滤掉
数据传递别碰全局变量和共享内存
Go 微服务之间不存在“共享内存”这回事。试图用 Redis 公共 key、ETCD 全局配置、甚至本地文件同步状态，本质上是把分布式系统降级成单机模型，放大一致性风险。典型翻车场景：A 服务写入 Redis key，B 服务读取时网络抖动导致缓存击穿，接着 fallback 到本地 map，结果不同实例返回不同结果。
正向做法：
- 服务间只传必要字段，用 proto message 显式定义；禁止在 message 里塞
bytes或string存 JSON blob —— 这等于放弃 schema 演进能力 - 大文件、图片、视频等二进制数据，一律走对象存储（S3/minio），服务间只传 URL 和签名 token
- 需要强一致的状态协同（如库存扣减），必须走分布式事务框架（如 DTM）或最终一致性 + 补偿任务，而不是靠“先查再改”的本地逻辑
- 日志、指标、链路追踪数据全部走 sidecar（如 Envoy）或独立 agent（如 OpenTelemetry Collector），不混入业务调用路径
