错误：只检查 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 ，比只比 <code>== 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 行为，必须干预重定向流程。

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

实操建议：
— 设置 CheckRedirect 函数，在每次跳转前记录 via[len(via)-1].URL 和目标 req.URL
— 若只想停在第一次 3xx，返回 http.ErrUseLastResponse，此时 resp.StatusCode 就是 302，resp.Header.Get("Location") 可取跳转地址
— 注意：禁用重定向后，resp.Request.URL 才是初始请求 URL；启用时它指向最终地址

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

怎么区分超时、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）<br>— 只取首行诊断：<code>bufio.NewReader(resp.Body).ReadString('\n')
— 截断前 N 字节：io.LimitReader(resp.Body, 4096)
— 无论读到 EOF 还是 error，都必须调 resp.Body.Close()，否则底层连接无法复用

状态码判断本身很简单，难的是把网络错误、重定向、响应体读取、连接复用这四层逻辑串起来不漏不乱。尤其当 resp 和 err 同时存在（如超时后服务端仍发回 504 body）时，顺序和边界条件稍有偏差，就会埋下连接泄漏或监控失真的隐患。