如何在Golang中处理HTTP状态码错误_Golang状态码判断与处理技巧

顺亿

2026-10-06 • 👁 0人浏览过

Go 的 http.Client.Do() 不会因非 2xx 状态码返回 error，需显式检查 resp.StatusCode ≥ 300；应先处理网络错误（err != nil），再判断状态码，并按 4xx/5xx 分类处理，结合 CheckRedirect 控制重定向。判断

http.Response.StatusCode

是否表示错误 Go 的

http.Client.Do()

不会自动把非 2xx 状态码转为 error，它只在底层连接失败、超时或无法解析响应时返回 error。也就是说，

404

、

500

、

401

这类响应会正常返回

*http.Response

，但

resp.StatusCode

已经不是成功状态。正确做法是显式检查状态码范围：

if resp.StatusCode < 200 || resp.StatusCode >= 300 {
    // 处理业务错误，比如记录日志、封装自定义错误等
    return fmt.Errorf("HTTP %d: %s", resp.StatusCode, http.StatusText(resp.StatusCode))
}

http.StatusText(code)

能安全转成可读文本（如

404 → "Not Found"

），比硬编码字符串更可靠别只检查

!= 200

：有些 API 正常返回

201 Created

或

204 No Content

如果调用的是 RESTful 接口，建议按语义分组处理：比如

4xx

归为客户端错误（可重试需谨慎），

5xx

归为服务端错误（通常应重试）用

http.Client.CheckRedirect

捕获重定向失败默认情况下，

http.Client

会自动跟随

301

302

重定向，直到达到最大跳转次数（默认 10 次），然后才返回最终响应。但你可能想在重定向链中某一步就中断，比如发现跳到了不可信域名，或遇到了

307 Temporary Redirect

却不想自动带 body 重发。通过

CheckRedirect

回调可以干预：立即学习 “ go语言免费学习笔记（深入） ”；

client := &http.Client{
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        if len(via) >= 3 {
            return errors.New("too many redirects")
        }
        if req.URL.Host != "api.example.com" {
            return fmt.Errorf("redirect to unauthorized host: %s", req.URL.Host)
        }
        return nil
    },
}

回调在每次重定向前触发，

via

是已发生的请求切片（含原始请求），可用于审计路径若返回非 nil error，整个

Do()

调用将立即返回该 error，且

resp

为 nil 注意：这个机制不捕获

304 Not Modified

，它不算重定向，而是直接复用缓存响应区分网络错误与 HTTP 状态码错误常见误区是把

err != nil

和 “HTTP 错误” 混为一谈。实际上，

err

只反映传输层问题，比如 DNS 失败、连接拒绝、TLS 握手失败、读取超时；而

resp.StatusCode

是应用层协议字段，两者必须分开处理。 go语言参考手册中文CHM版 Go 是一个开源的编程语言，它能让构造简单、可靠且高效的软件变得容易。本文给大家带来Go参考手册，需要的可以来下载！ Go是从2007年末由Robert Griesemer, Rob Pike, Ken Thompson主持开发，后来还加入了Ian Lance Taylor, Russ Cox等人，并最终于2009年11月开源，在2012年早些时候发布了Go 1稳定版本。现在Go的开发已经是完全开放的，并且拥有一个活跃的社区。 Go 语言特色简洁、快速、安全并行、有趣、开源内存管理、v数组安全、编译下载典型错误写法：

// ❌ 错误：把网络错误和 404 当作同一类
if err != nil || resp.StatusCode != 200 {
    log.Fatal(err)
}

正确处理顺序应该是：

resp, err := client.Do(req)
if err != nil {
    // 处理连接失败、超时、证书错误等
    return fmt.Errorf("network error: %w", err)
}
defer resp.Body.Close()

if resp.StatusCode < 200 || resp.StatusCode >= 300 {
    // 处理 4xx/5xx 等语义错误
    return fmt.Errorf("HTTP %d: %s", resp.StatusCode, http.StatusText(resp.StatusCode))
}

务必先判

err

，再用

resp

；否则

resp

可能为 nil，panic

resp.StatusCode

在

err == nil

时一定有效，即使响应体为空（如

204

）某些代理或中间件可能返回

0

状态码（极少见），此时

http.StatusText(0)

返回空字符串，需额外防御封装可重试的 HTTP 请求并分类响应错误生产环境常需对临时性错误（如

502 Bad Gateway

、

503 Service Unavailable

）做指数退避重试，但对

400 Bad Request

或

401 Unauthorized

重试无意义。因此建议按状态码语义分层封装错误类型。示例结构：

type HTTPError struct {
    StatusCode int
    StatusText string
    IsTemporary bool
}

func (e *HTTPError) Error() string {
    return fmt.Sprintf("HTTP %d %s", e.StatusCode, e.StatusText)
}

func isTemporaryStatusCode(code int) bool {
    return code >= 500 && code < 600 || code == 429
}

429 Too Many Requests

虽属 4xx，但属于临时限流，适合重试（配合

Retry-After

header）不要仅靠状态码决定是否重试：还需检查

resp.Header.Get("Connection") == "close"

或是否有

Retry-After

字段重试逻辑中记得克隆

*http.Request

（因为 body 可能已被读取），用

req.Clone(req.Context())

真正容易被忽略的是：即使你封装了完美的错误分类，如果没关闭

resp.Body

，连接会一直占用，导致

net/http: connection refused

或

too many open files

—— 所有分支都得确保

Close()

被调用，哪怕只是

io.Copy(io.Discard, resp.Body)

。

相关文章