如何在Golang中实现API接口请求_Golang net/http与JSON处理实践_技术教程

用net/http发JSON POST需手动序列化并设Content-Type头；解析响应前须校验状态码和空体；超时应配置http.Client.Timeout；动态字段用json.RawMessage延迟解析。

如何用 `net/http` 发起带 JSON body 的 POST 请求

Go 标准库的 net/http 本身不自动序列化或解析 JSON，必须手动处理 bytes.Reader 和 Content-Type 头。漏设头或错用编码方式，会导致服务端返回 400 Bad Request 或静默忽略 body。

先用 json.Marshal 将结构体转为 []byte，别直接传 struct
创建 bytes.NewReader(data) 作为 http.NewRequest 的 body 参数
务必调用 req.Header.Set("Content-Type", "application/json")
记得检查 resp.Body 是否关闭：用 defer resp.Body.Close()

data := map[string]string{"name": "alice", "age": "25"}
payload, _ := json.Marshal(data)
req, _ := http.NewRequest("POST", "https://api.example.com/users", bytes.NewReader(payload))
req.Header.Set("Content-Type", "application/json")
client := &http.Client{}
resp, err := client.Do(req)
if err != nil {
log.Fatal(err)
}
defer resp.Body.Close()

如何安全地解析 API 返回的 JSON 响应

直接用 json.Unmarshal 解到未初始化的变量、或忽略 io.EOF / io.ErrUnexpectedEOF，容易 panic 或读取不全。尤其当响应体为空（如 204 No Content）时，json.Decode 会报错。

始终检查 resp.StatusCode 再解析，避免对 4xx/5xx 响应体做 JSON 解析
用指针接收结构体，避免复制；字段首字母大写（否则 json 包无法导出）
对可能为空的响应，先读取 resp.Body 到 []byte，再判断长度是否为 0
使用 json.Decoder 替代 json.Unmarshal 可节省内存（流式解码），但需注意它不吞掉多余字段

type UserResp struct {
    ID   int    `json:"id"`
    Name string `json:"name"`
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
log.Printf("HTTP error: %d", resp.StatusCode)
return
}
body, _ := io.ReadAll(resp.Body)
if len(body) == 0 {
// 空响应，按业务逻辑处理
return
}
var u UserResp
if err := json.Unmarshal(body, &u); err != nil {
log.Printf("JSON parse failed: %v", err)
return
}

如何设置超时和重试避免请求卡死

http.DefaultClient 默认无超时，遇到网络抖动或服务端 hang 住，goroutine 会永久阻塞。Go 1.19+ 推荐用 http.Client 配置 Timeout，而非依赖 context.WithTimeout —— 后者只控制连接建立阶段，不覆盖传输过程。

Timeout 是总耗时上限（含 DNS、连接、写入、读取），适用于大多数场景
若需更细粒度控制（比如单独设连接超时），用 Transport 的 DialContext 和 ResponseHeaderTimeout
简单重试建议用指数退避：time.Second * 1, time.Second * 2, time.Second * 4
不要对 POST 等非幂等请求盲目重试，除非确认服务端支持重复提交

client := &http.Client{
    Timeout: 10 * time.Second,
    Transport: &http.Transport{
        DialContext: (&net.Dialer{
            Timeout:   5 * time.Second,
            KeepAlive: 30 * time.Second,
        }).DialContext,
        ResponseHeaderTimeout: 5 * time.Second,
    },
}

为什么 `json.RawMessage` 在处理动态字段时不可少

当 API 返回结构不固定（比如某些字段类型随状态变化，或嵌套结构需延迟解析），硬编码 struct 会导致 json.Unmarshal 失败。用 json.RawMessage 可跳过即时解析，把原始字节缓存下来，后续按需处理。

json.RawMessage 本质是 []byte，不会触发反序列化，也不校验 JSON 有效性
适合用于“通用响应包装体”：如 { "code": 0, "data": {...} } 中的 data 字段
注意：它不自动 deep-copy，如果原 body 被复用或修改，RawMessage 内容可能被污染
解析前要确保它非空且是合法 JSON 片段（可用 json.Valid 快速校验）

type ApiResponse struct {
    Code int            `json:"code"`
    Data json.RawMessage `json:"data"`
}
var apiResp ApiResponse
if err := json.Unmarshal(body, &apiResp); err != nil {
return
}
if len(apiResp.Data) > 0 && !json.Valid(apiResp.Data) {
log.Println("invalid data JSON")
return
}
// 按 code 分支决定解析目标结构
if apiResp.Code == 0 {
var user UserResp
if err := json.Unmarshal(apiResp.Data, &user); err != nil {
// handle
}
}

实际项目里最容易被忽略的是响应体读取的完整性与错误分支的覆盖——不是所有 API 都严格遵循 REST 规范，有些 200 响应里塞了错误信息在 body，有些 500 却没给 body。别只盯着 err 变量，resp.StatusCode 和 body 内容都得看。