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。
