HTTP响应体直接解析JSON失败的常见原因：未检查resp.StatusCode是否为200～299范围、resp.Body未读取或重复读取、响应含BOM/HTML包装、未调用defer resp.Body.Close()、结构体字段名与JSON key不匹配、类型不一致（如字符串数字混用）、嵌套空值处理不当，以及未用http.Client设置超时和重试。
HTTP响应体直接解析JSON失败的常见原因
Go里用 http.Get 或 http.Post 拿到响应后，直接对 resp.Body 调用 json.Unmarshal 大概率会报错：「invalid character '' looking for beginning of value」或「unexpected end of JSON input」。根本原因是 resp.Body 是一个未读取的 io.ReadCloser，且可能被多次读取（比如你先 io.ReadAll 一次，再传给 json.Unmarshal，但没重置），或者响应本身不是纯JSON（比如带BOM、含HTML包装、服务端返回了重定向而没检查 resp.StatusCode）。
- 务必先检查
resp.StatusCode是否为 200～299 范围，否则直接解析可能拿到 HTML 错误页 -
resp.Body只能读一次；用完必须defer resp.Body.Close()，否则连接不释放 - 推荐统一用
io.ReadAll(resp.Body)一次性读出字节切片，再交给json.Unmarshal—— 避免流式读取时边界错乱
结构体字段名与JSON key不匹配怎么办
Go 的 json.Unmarshal 默认按字段名首字母大写（即导出字段）匹配 JSON key，且严格区分大小写。如果 API 返回的是 user_name，而你的结构体字段是 UserName，默认不会自动映射。
- 用 struct tag 显式声明：
UserName string `json:"user_name"` - 忽略空字段用
omitempty：例如ID int `json:"id,omitempty"` - 若 JSON 字段可能为字符串或数字（如某些老接口把数字当字符串返回），字段类型别硬写
int，改用json.Number或自定义UnmarshalJSON方法 - 嵌套对象、数组、空值（
null）都要对应结构体字段类型，比如 JSON 中是"tags": null，字段就不能是[]string，得是*[]string或[]string加判断逻辑
用 http.Client 控制超时和重试更可靠
直接用 http.Get 看似简单，但它底层用的是默认 http.DefaultClient，没有设置超时，容易卡死；也不支持自动重试或自定义 Header。
client := &http.Client{
Timeout: 10 * time.Second,
}
req, _ := http.NewRequest("GET", "https://api.example.com/data", nil)
req.Header.Set("Accept", "application/json")
req.Header.Set("User-Agent", "MyApp/1.0")
<p>resp, err := client.Do(req)
if err != nil {
// 处理网络错误（超时、DNS失败等）
}
if resp.StatusCode != http.StatusOK {
// 处理业务错误状态码
}
defer resp.Body.Close()</p><p>body, _ := io.ReadAll(resp.Body)
var data MyResponse
if err := json.Unmarshal(body, &data); err != nil {
// 处理解析错误
}遇到嵌套动态JSON或未知字段怎么办
有些API返回结构不固定：比如 {"result": {...}} 里的 result 可能是对象、数组或 null；或者字段名是运行时生成的（如 "2024-01-01" 这样的日期键）。这时候强依赖结构体就不可行。
- 用
map[string]interface{}或map[string]json.RawMessage做中间层解析，延迟解构 -
json.RawMessage能跳过解析，保留原始字节，适合后续按需处理（比如只取某个子字段再解析） - 避免对
interface{}直接断言，先用类型断言 +ok判断，例如：if v, ok := data["items"].([]interface{}); ok { ... } - 第三方库如
gjson更适合高频查询动态 JSON，但引入依赖前先确认是否真有必要——多数场景json.RawMessage+ 手动分支已足够
实际项目中，最常被忽略的是 resp.StatusCode 检查和 resp.Body.Close() 的调用时机。这两个点不出问题时一切正常，一出就是连接泄漏或静默解析失败。
