Golang怎么处理HTTP响应_Golang HTTP响应处理教程【对比】

Go处理HTTP响应必须手动关闭resp.Body并检查StatusCode：不关会导致连接池阻塞和文件描述符耗尽；不查状态码会忽略404/500等业务错误；Content-Type须以响应头为准，不可硬猜编码。Go 处理 HTTP 响应，核心就三件事：别漏关 resp.Body、别跳过 StatusCode 检查、别硬猜 Content-Type。少做一步，轻则数据错乱，重则连接耗尽、服务假死。为什么必须手动调用 resp.Body.Close()Go 的 http.Client 不会自动关闭响应体------它把责任交给你。不关，TCP 连接就卡在连接池里，下次复用时可能读到上一次的残留数据；更严重的是，文件描述符持续增长，最终触发 too many open files 错误，整个服务夯住。错误写法：body, _ := io.ReadAll(resp.Body) 后直接结束，没关正确姿势：在 err == nil 分支开头立刻加 defer resp.Body.Close()（注意：resp 为 nil 时不能 defer）即使你用 json.NewDecoder(resp.Body).Decode(&v) 流式解析，也得关------它不负责关如果后续要多次读取 body（极少见），得先用 io.ReadAll 拷贝出来，再重新构造 bytes.NewReader怎么判断响应算"成功"而不是只看 err == nilhttp.Get 或 client.Do 的 err 只管网络层（连不上、超时、TLS失败等），不管业务逻辑。404、500、422 全都返回 err == nil，但 resp.StatusCode 已经不是你想的那样了。别写 if err != nil 就完事------这只能捕获连接失败，漏掉全部 HTTP 错误码必须显式检查：if resp.StatusCode = 300，或更常见地用 resp.StatusCode >= 400非 2xx 响应体往往含错误详情（如 {"error": "invalid_token"}），建议读出来并包装进自定义 error重定向（301/302）默认自动跟随，若需拦截，得配 CheckRedirect；304 响应体为空，但头里有缓存信息，别直接 ReadAll 报 panic怎么安全解析 resp.Body 而不崩在编码或格式上响应头里的 Content-Type 是唯一可信依据。别假设是 UTF-8，也别靠 string(bodyBytes) 硬转------BOM、GBK、ISO-8859-1 都可能真实存在。 Trenz AI驱动的社交电商营销平台，专为TikTok Shop设计