Go处理HTTP响应需先检查StatusCode≥300再读Body,及时Close()防止连接耗尽;小JSON用io.ReadAll,大或流式用json.NewDecoder;Content-Type决定编码处理,流式响应须用bufio按行读取并及时解码。
Go 处理 HTTP 响应数据,核心不是“怎么读”,而是“什么时候读、读多少、读完怎么用”。
状态码
没检查就急着
,Body 没
就返回,JSON 解析前不看
—— 这些都会让程序在压测时连接耗尽、线上突然 OOM、或解析出空结构体却查不出原因。
先 check StatusCode,再碰 Body
很多 bug 都源于把 404/500 当成成功响应处理。Go 的
不会自动拒绝非 2xx 响应,它只管传数据。
必须显式判断:
(比只判
更稳妥,覆盖 201/204 等合法非 200 场景)
非成功状态也得读并关掉
,否则连接无法复用,高并发下
或
就来了
错误提示建议带原始响应体(限长):
,再
读 Body:io.ReadAll 还是
js
on.NewDecoder?
取决于你对内存和格式的信任程度。小 JSON 响应两者差别不大;大响应或流式接口,选错就容易 OOM 或解析失败。
:简单直接,但整块进内存 —— 下载 500MB 文件时会瞬间吃光 1GB RAM
:边读边解,支持 UTF-8 BOM 自动跳过,且不占额外内存;适合单个 JSON 对象
如果是 JSON 数组流(如 NDJSON),用
别忘了:无论哪种方式,
仍需
Content-Type 和
编码
不能靠猜
HTTP 响应头里的
是唯一可信线索,比如
—— Go
标准库
的
会直接 panic。
php版微信js-sdk支付接口类
php版微信js-sdk支付接口类
下载
先打印调试:
若含
或
,用
转 UTF-8 再解码
纯文本或 HTML 响应,别用
硬转 —— BOM、换行符、\u0000 都可能让字符串截断或解析异常
HTML 解析务必用
,正则提取
类操作在真实页面中基本不可靠
流式响应(SSE / JSON Stream)必须用 bufio
服务端用
或逐行推送 JSON,
会一直阻塞到连接关闭 —— 而流式连接本就不关。
用
包装响应体
按行读:
;按分隔符读:
循环中检测
表示流结束;
才是真错误
每行处理完记得
,别 accumulate 到切片里等最后处理 —— 否则又变内存黑洞
最常被跳过的其实是
的位置 —— 它必须在所有 error 分支之后、函数退出前执行,哪怕你只读了前 10
字节
。Go 不会替你记着这个连接,它只等你关。
io.ReadAllClose()Content-Typehttp.Responseif resp.StatusCode = 300!= http.StatusOKresp.Bodynet/http: timeout awaiting response headerstoo many open filesbody, _ := io.ReadAll(io.LimitReader(resp.Body, 1024))defer resp.Body.Close()io.ReadAll(resp.Body)json.NewDecoder(resp.Body).Decode(&v)decoder := json.NewDecoder(resp.Body); for decoder.More() { decoder.Decode(&item) }resp.Bodydefer resp.Body.Close()Content-Typeapplication/json; charset=gbkjson.Unmarshallog.Printf("Content-Type: %s", resp.Header.Get("Content-Type"))charset=gbkcharset=gb2312golang.org/x/text/encodingstring(bodyBytes)golang.org/x/net/htmltext/event-streamio.ReadAllreader := bufio.NewReader(resp.Body)line, err := reader.ReadBytes('\n')reader.ReadBytes('\x00')err == io.EOFerr != nil && err != io.EOFjson.Unmarshal(line, &event)resp.Body.Close()