HTTP客户端必须设超时，否则会无限阻塞；结构体字段需大写并加json tag；强一致性场景应选gRPC；上下文信息须通过header或metadata传递；连接池与Keepalive参数不可忽略。
用 HTTP 客户端调用其他 Go 服务时，http.Client 要设超时
不设超时的 http.Client 在对方服务卡住或网络异常时会无限阻塞，拖垮调用方。Go 默认的 http.DefaultClient 没有设置超时，不能直接用于生产跨服务调用。
- 必须显式创建带超时的客户端：
http.Client{Timeout: 5 * time.Second} - 连接超时（
net.Dialer.Timeout）和读写超时（Transport.ResponseHeaderTimeout）最好分开控制，尤其在长响应场景下 - 避免复用全局
http.Client实例做大量并发请求却不设MaxIdleConnsPerHost，否则可能耗尽文件描述符
JSON API 通信中，json.Unmarshal 失败但没报错？检查结构体字段导出性
Go 的 json 包只能序列化/反序列化**首字母大写的导出字段**。如果结构体字段是小写（如 id int），json.Unmarshal 不会报错，但对应字段始终为零值——这是跨服务调试中最常被忽略的静默失败。
- 结构体字段必须以大写字母开头，且建议加上
jsontag 显式声明键名：ID int `json:"id"` - 接收方用
json.RawMessage延迟解析，可绕过字段不匹配导致的 panic，适合兼容多版本响应 - 发送前用
json.Marshal+string()打印原始字节，比只看结构体变量更可靠
服务间需要强一致性或实时通知？别硬扛 HTTP，改用 gRPC + Protocol Buffers
HTTP+JSON 适合松耦合、低频、人类可读的交互；一旦出现流式数据、双向通信、或需要精确错误码（如 NOT_FOUND、RESOURCE_EXHAUSTED），HTTP 就开始暴露短板。
- gRPC 默认基于 HTTP/2，天然支持流式调用（
stream）、拦截器、截止时间传播 - Protocol Buffers 的 IDL 强制契约先行，生成的 Go 代码自带类型安全和序列化逻辑，省去手写
struct和jsontag - 注意：gRPC over HTTP/2 在某些代理（如 Nginx 旧版）或 TLS 终止层可能被降级成 HTTP/1.1，导致连接失败——需确认中间件支持 HTTP/2 ALPN
跨服务传上下文（如 traceID、用户身份）时，别往 URL 或 body 里塞，用 metadata.MD 或 HTTP header
在 HTTP 场景下，traceID、auth-token 这类元数据应走标准 header（如 X-Request-ID、Authorization），而非拼进 query 或 JSON body。gRPC 则应使用 metadata.MD，它会被自动编码进 HTTP/2 headers。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 客户端发请求前，用
req.Header.Set("X-Trace-ID", traceID)注入；服务端用r.Header.Get("X-Trace-ID")提取 - gRPC 客户端：用
metadata.Pairs("trace-id", traceID)构造metadata.MD，再传给ctx - 服务端从
grpc.RequestMetadata(ctx)获取，不要试图从context.Value里硬塞——那不是跨进程传递上下文的正确方式
实际部署中，最易被忽略的是 HTTP 客户端连接池配置 和 gRPC 的 Keepalive 参数：前者影响瞬时并发能力，后者决定空闲连接是否被中间设备（如云负载均衡器）静默断开。这两个点不调，服务看着正常，压测或夜间低流量时却频繁报 connection reset by peer 或 context deadline exceeded。
