用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")
<p>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"`
}
<p>if resp.StatusCode < 200 || resp.StatusCode >= 300 {
log.Printf("HTTP error: %d", resp.StatusCode)
return
}</p><p>body, _ := io.ReadAll(resp.Body)
if len(body) == 0 {
// 空响应，按业务逻辑处理
return
}</p><p>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 可跳过即时解析，把原始字节缓存下来，后续按需处理。
立即学习“go语言免费学习笔记（深入）”；
-
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"`
}
<p>var apiResp ApiResponse
if err := json.Unmarshal(body, &apiResp); err != nil {
return
}</p><p>if len(apiResp.Data) > 0 && !json.Valid(apiResp.Data) {
log.Println("invalid data JSON")
return
}</p><p>// 按 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 内容都得看。
