如何在Golang中统一处理HTTP请求错误_Golang网络请求错误处理方法

http请求失败时resp可能为nil而err非网络错误；需先判err再查StatusCode，及时Close Body并配置超时，封装错误类型，避免盲目defer关闭Body。

HTTP请求失败时，resp 为 nil，但 err 不一定代表网络错误

go 的 http.DefaultClient.Do() 返回两个值：resp *http.Response 和 err Error。很多人误以为只要 err != nil 就说明请求没发出去，其实不然——比如服务端返回 500 或 404，err 仍为 nil，resp 存在但状态码异常。
这时候如果直接 resp.Body.Close() 前不做 resp != nil 判断，会 panic。

• 先检查 err：非 nil 通常表示连接失败、超时、dns 解析失败等底层问题
• 再检查 resp.StatusCode：即使 err == nil，也要判断是否在 200–299 范围内
• 永远在使用完 resp.Body 后调用 resp.Body.Close()，否则连接不会复用，容易耗尽文件描述符

用 http.Client 配置超时，避免请求无限挂起

默认的 http.DefaultClient 没有设置超时，遇到网络卡顿或服务无响应时，goroutine 会长时间阻塞。必须显式配置 Timeout 或更细粒度的 Transport 参数。

• Timeout 是总超时（从发起请求到读完响应体），适合大多数场景
• 若需分别控制连接、读写超时，应自定义 http.Transport，例如设置 DialContext、ResponseHeaderTimeout
• 不要复用未设超时的全局 client，尤其在高并发 HTTP 客户端中

client := &http.Client{     Timeout: 10 * time.Second, }

封装统一错误类型，区分网络错误、协议错误、业务错误

原始的 error 接口太泛，无法快速判断错误性质。建议定义一个结构体，携带错误分类、原始 err、HTTP 状态码、响应体片段等信息，便于日志记录和重试策略。

• 网络层错误（如 net.OpError、url.Error）可归为 NetworkErr
• HTTP 状态码非 2xx 属于 HTTPStatusErr，应附带 resp.StatusCode 和可能的 Content-Type
• 解析 jsON 失败、字段缺失等属于 DecodeErr，和 HTTP 层解耦

type HTTPError struct {     Kind     string     Status   int     RawBody  []byte     Cause    error }

别在中间件里盲目 defer resp.Body.Close()

常见反模式：写一个通用 HTTP 请求函数，在入口处 defer resp.Body.Close()。这会导致 body 提前关闭，后续无法读取内容，尤其是需要多次读取或流式处理时。

立即学习“go语言免费学习笔记（深入）”；

• resp.Body 只能被读取一次，且必须全部读完（或显式 io.copy(ioutil.Discard, ...)）才能释放连接
• 正确做法是：在确定不再需要 body 后立即关闭，比如读完 io.ReadAll 之后
• 若需复用 body（如日志记录 + 后续解析），可用 bytes.NewReader 包装已读内容，但要注意内存开销

最易被忽略的是：当 err != nil 且 resp == nil 时，resp.Body 根本不存在，此时调用 Close() 会 panic。