gRPC内部调用必须显式配置服务端KeepaliveParams、全局复用*grpc.ClientConn单例、统一用status.Errorf构造错误，否则将引发连接断开、TIME_WAIT激增及熔断失效等问题。
内部微服务之间调用，gRPC 是默认选择，不是因为它“简单”，而是它在类型安全、连接复用、流控能力和契约一致性上几乎没有替代方案；HTTP/JSON 只该用于对外暴露或临时桥接，硬塞进内部调用链会埋下静默失败、字段错位、goroutine 泄漏等隐患。
gRPC 调用必须做这三件事，否则上线就出问题
很多团队跑通第一个 grpc.Dial 就以为完成了，实际生产环境里，以下三点缺一不可：
- 服务端必须显式配置
grpc.KeepaliveParams，否则 Kubernetes 的 Service Mesh（比如 Istio）会在 15 分钟左右无流量时主动断开长连接，导致后续请求报rpc error: code = Unavailable desc = transport is closing - 客户端不要把
*grpc.ClientConn当成一次性的——每次调用都grpc.Dial再Close，不仅性能差，还会触发大量 TIME_WAIT；应封装为单例或通过依赖注入传递 - 错误必须用
status.Errorf(code, msg)构造，禁止errors.New或fmt.Errorf；否则下游无法用status.Code(err)提取标准码，熔断、重试、日志分类全失效
HTTP/JSON 调用不是不能用，但得守住这几条底线
如果你非要用 http.Client 调另一个 Go 微服务（比如旧系统还没迁完），这些不是建议，是硬性约束：
- 必须设置超时：
http.Client不能复用http.DefaultClient，要基于context.WithTimeout构建新 client，且 timeout 值 ≤ 上游 context 的 deadline - 反序列化必须用
jsoniter.ConfigCompatibleWithStandardLibrary替代标准encoding/json，它对空字符串转 struct 字段、NaN 处理更鲁棒，避免零值静默覆盖 - 请求体禁止传
map[string]interface{}—— 类型信息彻底丢失，下游没法做字段级校验；必须定义明确 struct，所有字段导出（首字母大写）
Context 透传不是可选项，是调用链的呼吸系统
没有 context.Context 贯穿整个调用链，你就等于放弃了 traceID 注入、超时控制、取消传播和链路追踪。常见断裂点：
立即学习“go语言免费学习笔记（深入）”；
- HTTP 中间件从
X-Request-ID解析出 traceID，但没把它写进 gRPC 的 metadata；结果 gateway 到 service A 正常，A 调 B 就断了 - GRPC 客户端写 metadata 时用了
X-Trace-ID，服务端却按traceparent格式解析（W3C 标准），导致 OTel Collector 直接丢弃 span - 异步 goroutine（比如发消息、写日志）没显式传入
ctx或span，日志里 trace_id 为空，查问题时找不到上下文
最常被忽略的是：GRPC 的 metadata 和 context 是两套独立容器，context.WithValue(ctx, key, val) 不会自动同步到 outgoing metadata；必须用 metadata.AppendToOutgoingContext(ctx, "traceparent", traceparentStr) 才行。
