如何在Golang中实现跨服务通信_Golang Web服务间通信与数据传输-Golang

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 不会报错，但对应字段始终为零值——这是跨服务调试中最常被忽略的静默失败。

• 结构体字段必须以大写字母开头，且建议加上 json tag 显式声明键名：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 和 json tag
• 注意：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。