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 响应两者差别不大；大响应或流式接口，选
-
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 是唯一可信线索，比如 application/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 不会替你记着这个连接，它只等你关。
