Go如何处理HTTP响应数据_HTTP响应读取方式

Go处理HTTP响应需先检查StatusCode≥300再读Body，及时Close()防止连接耗尽；小JSON用io.ReadAll，大或流式用json.NewDecoder；Content-Type决定编码处理，流式响应须用bufio按行读取并及时解码。

Go 处理 HTTP 响应数据，核心不是“怎么读”，而是“什么时候读、读多少、读完怎么用”。状态码没检查就急着 io.ReadAll，Body 没 Close() 就返回，JSON 解析前不看 Content-Type —— 这些都会让程序在压测时连接耗尽、线上突然 OOM、或解析出空结构体却查不出原因。

先 check StatusCode，再碰 Body

很多 bug 都源于把 404/500 当成成功响应处理。Go 的 http.Response 不会自动拒绝非 2xx 响应，它只管传数据。

• 必须显式判断：if resp.StatusCode = 300（比只判 != http.StatusOK 更稳妥，覆盖 201/204 等合法非 200 场景）
• 非成功状态也得读并关掉 resp.Body，否则连接无法复用，高并发下 net/http: timeout awaiting response headers 或 too many open files 就来了
• 错误提示建议带原始响应体（限长）：body, _ := io.ReadAll(io.LimitReader(resp.Body, 1024))，再 defer resp.Body.Close()

读 Body：io.ReadAll 还是 json.NewDecoder？

取决于你对内存和格式的信任程度。小 JSON 响应两者差别不大；大响应或流式接口，选错就容易 OOM 或解析失败。

• io.ReadAll(resp.Body)：简单直接，但整块进内存 —— 下载 500MB 文件时会瞬间吃光 1GB RAM
• json.NewDecoder(resp.Body).Decode(&v)：边读边解，支持 UTF-8 BOM 自动跳过，且不占额外内存；适合单个 JSON 对象
• 如果是 JSON 数组流（如 NDJSON），用 decoder := json.NewDecoder(resp.Body); for decoder.More() { decoder.Decode(&item) }
• 别忘了：无论哪种方式，resp.Body 仍需 defer resp.Body.Close()

Content-Type 和编码不能靠猜

HTTP 响应头里的 Content-Type 是唯一可信线索，比如 applicat

ion/json; charset=gbk —— Go 标准库的 json.Unmarshal 会直接 panic。

• 先打印调试：log.Printf("Content-Type: %s", resp.Header.Get("Content-Type"))
• 若含 charset=gbk 或 charset=gb2312，用 golang.org/x/text/encoding 转 UTF-8 再解码
• 纯文本或 HTML 响应，别用 string(bodyBytes) 硬转 —— BOM、换行符、\u0000 都可能让字符串截断或解析异常
• HTML 解析务必用 golang.org/x/net/html，正则提取 类操作在真实页面中基本不可靠

流式响应（SSE / JSON Stream）必须用 bufio

服务端用 text/event-stream 或逐行推送 JSON，io.ReadAll 会一直阻塞到连接关闭 —— 而流式连接本就不关。

• 用 reader := bufio.NewReader(resp.Body) 包装响应体
• 按行读：line, err := reader.ReadBytes('\n')；按分隔符读：reader.ReadBytes('\x00')
• 循环中检测 err == io.EOF 表示流结束；err != nil && err != io.EOF 才是真错误
• 每行处理完记得 json.Unmarshal(line, &event)，别 accumulate 到切片里等最后处理 —— 否则又变内存黑洞

最常被跳过的其实是 resp.Body.Close() 的位置 —— 它必须在所有 error 分支之后、函数退出前执行，哪怕你只读了前 10 字节。Go 不会替你记着这个连接，它只等你关。