错误：只检查 err != nil 就认为请求成功；正确做法是必须显式判断 resp.StatusCode >= 200 && resp.StatusCode
只检查
err != nil就认为请求成功？这是最危险的错觉Go 的
http.Get和client.Do在服务端返回 404、500、甚至 HTML 错误页时，err依然是nil——只要 TCP 连通、HTTP 响应头能收回来，网络层就算“成功”。此时resp非空，但resp.StatusCode已经是业务失败信号。常见错误现象：
— 把{"code":401,"msg":"unauthorized"}当成正常数据反序列化，字段缺失 panic
— 日志里全是 “200 OK”，实际大量 4xx 请求被当成成功上报
— 监控告警漏掉认证过期、限流拒绝等关键业务异常正确做法：
— 必须显式判断resp.StatusCode >= 200 && resp.StatusCode ，比只比== http.StatusOK更健壮（兼容 201、204）
—defer resp.Body.Close()要写在状态码检查之前，否则 panic 时 body 漏关，连接复用失效
— 即使状态码异常，也要读取resp.Body（比如 JSON 错误体），但要用http.MaxBytesReader限流防 OOM
http.Client默认会吞掉 3xx 重定向？怎么拿到原始跳转链默认情况下，
http.Client会自动跟随 301/302/307/308，最终返回的是重定向终点的响应，resp.StatusCode是 200（或终点返回的状态码），原始 302 不可见。如果你需要分析跳转路径、防止 SSRF 或调试 API 行为，必须干预重定向流程。实操建议：
— 设置CheckRedirect函数，在每次跳转前记录via[len(via)-1].URL和目标req.URL
— 若只想停在第一次 3xx，返回http.ErrUseLastResponse，此时resp.StatusCode就是 302，resp.Header.Get("Location")可取跳转地址
— 注意：禁用重定向后，resp.Request.URL才是初始请求 URL；启用时它指向最终地址怎么区分超时、DNS 失败和 500？别再用字符串匹配
"timeout"所有网络层错误（连接超时、读取超时、DNS 解析失败、连接被拒）都走
err != nil分支，但它们语义完全不同。用strings.Contains(err.Error(), "timeout")匹配既脆弱又违反 Go 错误处理原则。正确分类方式：
— 用errors.As(err, &netErr)断言是否为net.Error，再调netErr.Timeout()精准识别超时（含连接、读取、TLS 握手等）
— 其他网络错误可进一步用errors.Is(err, syscall.ECONNREFUSED)或检查netErr.Temporary()判断是否可重试
— 若err == nil但resp.StatusCode >= 500，属于服务端故障，不应归为客户端错误非 2xx 响应体怎么安全读？不读会丢错误信息，全读可能 OOM
服务端对 4xx/5xx 响应仍可能返回大体积 body：HTML 错误页、堆栈日志、debug dump。直接
io.ReadAll(resp.Body)在高并发下极易触发内存溢出。可控读取策略：
— 限制总长：io.ReadAll(http.MaxBytesReader(nil, resp.Body, 1（最多 1MB）
— 只取首行诊断：bufio.NewReader(resp.Body).ReadString('\n')
— 截断前 N 字节：io.LimitReader(resp.Body, 4096)
— 无论读到 EOF 还是 error，都必须调resp.Body.Close()，否则底层连接无法复用状态码判断本身很简单，难的是把网络错误、重定向、响应体读取、连接复用这四层逻辑串起来不漏不乱。尤其当
resp和err同时存在（如超时后服务端仍发回 504 body）时，顺序和边界条件稍有偏差，就会埋下连接泄漏或监控失真的隐患。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
