HTTP响应体必须显式读取并关闭，否则会导致连接复用污染、数据丢失和文件描述符泄漏；大JSON应流式解码；非2xx响应体含错误信息需统一处理；文本响应需按Content-Type或meta/xml声明的charset解码。
HTTP响应体必须显式读取，否则连接可能被复用但数据丢失
Go 的 http.Client 发起请求后，resp.Body 是一个 io.ReadCloser，它不会自动读取或关闭。如果忽略 resp.Body，底层 TCP 连接可能被保留在连接池中，但未读取的响应体数据会滞留在缓冲区，下次复用该连接时可能污染新请求的响应流（尤其在 HTTP/1.1 持久连接下）。更严重的是，不调用 resp.Body.Close() 会导致文件描述符泄漏。
正确做法是：无论是否需要响应体内容，都必须读取并关闭：
resp, err := http.Get("https://api.example.com/data")
if err != nil {
log.Fatal(err)
}
defer resp.Body.Close() // 必须放在这里，不是在 error check 后
body, err := io.ReadAll(resp.Body) // 显式读取全部
if err != nil {
log.Fatal(err)
}
// 现在 body 是 []byte，可进一步解析
JSON响应直接用json.NewDecoder流式解码，避免内存峰值
当响应体较大（比如几 MB 的 JSON 数组）时，先用 io.ReadAll 加载全部再 json.Unmarshal 会造成双倍内存占用（原始字节 + Go 结构体）。更高效的方式是用 json.NewDecoder 直接从 resp.Body 流式解码。
-
json.NewDecoder内部按需读取，不缓存整个 body - 解码失败时，
resp.Body可能已部分读取，无法重试（除非提前io.Copy(ioutil.Discard, ...)清空） - 适用于单个 JSON 值（对象或数组），不支持多个连续 JSON 值（需用
json.Decoder.Token()手动控制）
示例：
立即学习“go语言免费学习笔记（深入）”；
type User struct {
ID int `json:"id"`
Name string `json:"name"`
}
resp, _ := http.Get("https://api.example.com/user/123")
defer resp.Body.Close()
var user User
if err := json.NewDecoder(resp.Body).Decode(&user); err != nil {
log.Fatal(err) // 注意：err 可能来自网络读取或 JSON 语法错误
}
resp.StatusCode 不等于 200 时，resp.Body 仍可能含有效错误信息
很多 REST API 在出错时（如 400、404、500）仍会返回 JSON 格式的错误详情（{"error": "not found", "code": "NOT_FOUND"}），而不是空 body。直接忽略非 2xx 响应体，会丢失关键调试线索。
用于端到端视频本地化流程的轻量编排器，路由至四个专注子技能——/wjs-transcribing-audio、/wjs-translating-subtitles...
建议统一处理流程：
- 先检查
resp.StatusCode是否在预期范围内（如200 ） - 再读取
resp.Body—— 无论状态码如何，都要defer resp.Body.Close() - 对非成功响应，尝试解析其 body 为错误结构体，而非直接 panic 或 log "HTTP error"
例如：
resp, err := client.Do(req)
if err != nil {
return err
}
defer resp.Body.Close()
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
var apiErr struct {
Error string `json:"error"`
Code string `json:"code"`
}
if err := json.NewDecoder(resp.Body).Decode(&apiErr); err == nil {
return fmt.Errorf("API error %s: %s", apiErr.Code, apiErr.Error)
}
return fmt.Errorf("HTTP %d, failed to decode error body", resp.StatusCode)
}
处理文本类响应（HTML/XML/纯文本）注意字符编码和 Content-Type 中的 charset
Go 的 http.Response 不自动处理字符编码转换。resp.Header.Get("Content-Type") 可能包含类似 text/html; charset=utf-8 或 application/xml; charset=gbk 的值，但 resp.Body 返回的仍是原始字节流。
- 若服务端声明了
charset，应优先按该编码解码（可用golang.org/x/text/encoding包） - 若未声明 charset，默认按 UTF-8 解释；但 HTML 可能在
<meta charset="gb2312">中声明，此时需先解析 HTML 获取编码，再重新解码（较重，一般服务端应规范返回 charset） - XML 响应同理，首行如
<?xml version="1.0" encoding="GBK"?>需手动识别
简单场景下可强制 UTF-8 解码并忽略错误（适合已知服务端编码一致）：
body, _ := io.ReadAll(resp.Body) text := string(body) // 前提：body 确实是 UTF-8 编码
真正需要处理多编码时，别硬写，用 charset.NewReaderLabel 或 encoding/xml.Decoder 自带的 charset 支持。
resp.Body 的读取和关闭 —— 看似省了一行代码，却让错误排查变成猜谜。 
