Go问答：http.ProtocolError客户端遇到协议错误时怎样区分原因怎样完成一个可复用的最小示例

遇到 Go HTTP 客户端报错时，不要先把所有错误都归到 http.ProtocolError。更稳妥的做法是先看请求有没有得到响应，再沿着错误链用 errors.As 和 errors.Is 判断类型；如果已经拿到响应，则优先处理 HTTP 状态码。这样能把“连不上”“协议解析失败”和“服务端返回 5xx”分成三条排查路径。

结论：http.ProtocolError 仍可用于兼容识别，但它已经被官方标记为 deprecated，并不代表 net/http 中所有协议相关错误。代码应保留错误链、先区分 resp 与 err，再按类型和状态码输出诊断信息。

先把三类结果分开

客户端调用 client.Do(req) 后，最重要的第一层判断是 resp 是否存在。没有响应时，问题通常发生在请求发送、连接建立或响应解析过程中；有响应时，哪怕状态码是 404 或 500，也不应当把它当成 Go 层面的协议错误。

为什么不能只判断 ProtocolError

当前 net/http 文档把 ProtocolError 标记为 deprecated，原因是 HTTP 包中与协议相关的错误并不都使用这个类型。也就是说，下面的判断可以兼容一部分旧代码和底层返回，但不能当成“协议错误总开关”。

package main

import (
    "errors"
    "fmt"
    "net/http"
)

func classifyError(err error) string {
    if err == nil {
        return "没有客户端错误"
    }

    // errors.As 会沿着 %w 包装链查找具体类型，避免被 *url.Error 遮住。
    var protocolErr *http.ProtocolError
    if errors.As(err, &protocolErr) {
        return "兼容识别为 HTTP 协议错误：" + protocolErr.Error()
    }

    // 没有命中具体类型时，保留原始错误文本供日志和上层策略使用。
    return "传输或其它客户端错误：" + err.Error()
}

func main() {
    // 这里故意构造一个被 url.Error 包装的协议错误，演示错误链识别。
    err := &http.ProtocolError{ErrorString: "响应行格式无效"}
    fmt.Println(classifyError(err))
}

生产代码里不要用 err.Error() 的文本做唯一分支条件。文本适合日志，不适合稳定的程序判断；如果某个错误有官方哨兵值或明确类型，优先使用 errors.Is 或 errors.As。

封装一个可复用的诊断函数

把响应状态和错误分类放进同一个函数，可以让业务层只关心“请求成功、收到业务错误响应、还是客户端阶段失败”。下面的函数返回简短结果，调用方仍然可以保留原始 error 写日志或继续向上包装。

package httpdiag

import (
    "errors"
    "fmt"
    "net/http"
)

func Diagnose(resp *http.Response, err error) string {
    if err != nil {
        // 没有响应时先看错误链，不要读取不存在的响应体。
        var protocolErr *http.ProtocolError
        if errors.As(err, &protocolErr) {
            return "protocol: " + protocolErr.Error()
        }
        return "transport-or-client: " + err.Error()
    }
    if resp == nil {
        // RoundTripper 返回 nil 响应和 nil 错误属于调用契约异常。
        return "client-contract: nil response"
    }
    defer resp.Body.Close()

    // 有响应就按 HTTP 语义判断，4xx/5xx 不是 ProtocolError。
    if resp.StatusCode >= 400 {
        return fmt.Sprintf("http-status: %s", resp.Status)
    }
    return fmt.Sprintf("ok: %s", resp.Status)
}

用最小示例覆盖协议错误和 HTTP 状态码

为了让分类逻辑可重复，测试时可以使用自定义 RoundTripper 注入错误，再用 httptest 模拟一个真实的 HTTP 状态码响应。前者验证错误链，后者验证“有响应就看状态码”的边界。

package main

import (
    "errors"
    "fmt"
    "net/http"
    "net/http/httptest"
)

type roundTripFunc func(*http.Request) (*http.Response, error)

func (f roundTripFunc) RoundTrip(r *http.Request) (*http.Response, error) {
    // 自定义传输层只用于注入可控结果，不代表真实网络返回格式。
    return f(r)
}

func main() {
    protocolClient := &http.Client{
        Transport: roundTripFunc(func(_ *http.Request) (*http.Response, error) {
            // 用 %w 让上层仍能通过 errors.As 识别底层 ProtocolError。
            return nil, fmt.Errorf("读取响应失败: %w", &http.ProtocolError{ErrorString: "首行无效"})
        }),
    }
    req, _ := http.NewRequest(http.MethodGet, "http://example.invalid", nil)
    _, err := protocolClient.Do(req)

    var protocolErr *http.ProtocolError
    fmt.Println("protocol error:", errors.As(err, &protocolErr))

    server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, _ *http.Request) {
        // 返回业务层失败状态，模拟“请求到达但结果不成功”。
        http.Error(w, "temporary failure", http.StatusBadGateway)
    }))
    defer server.Close()

    resp, err := http.Get(server.URL)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    fmt.Println("http status:", resp.StatusCode)
}

这个例子刻意把两种场景放在一起：第一段没有响应，说明客户端阶段发生了错误；第二段拿到了 502 Bad Gateway 响应，说明 HTTP 交换完成，但业务或网关结果失败。真实项目中还应读取有限长度的响应体、记录请求方法和目标主机，并给请求设置超时或上下文取消。

迁移旧代码时检查这几处

1. 保留错误包装：补充上下文时使用 fmt.Errorf("...: %w", err)，不要把类型信息抹成普通字符串。
2. 分开处理 resp 和 err：err != nil 时不要假设一定有可读的响应体；resp != nil 时记得关闭 Body。
3. 兼容识别而不是硬编码：旧代码需要判断 *http.ProtocolError 时用 errors.As，但同时准备其它协议错误和传输错误的兜底路径。
4. 不要把 4xx/5xx 直接当网络故障：先根据状态码决定重试、降级还是返回业务错误，重试策略应考虑请求是否幂等。

小结

http.ProtocolError 的正确定位是“可兼容识别的一个协议错误类型”，而不是 net/http 的全部错误分类。最小可靠流程是：调用 client.Do 后先判断是否有响应；无响应时沿错误链使用 errors.As/errors.Is，有响应时读取状态码并按 HTTP 语义处理。这样既兼容旧代码，也能避免因为错误文本或单一类型判断造成误诊。

相关问题

• 为什么 errors.As 比字符串判断更适合排错？ 因为它可以穿过 *url.Error 和自定义 %w 包装，直接检查错误类型。
• 拿到 500 响应时 err 会不会非空？ 正常的 HTTP 500 通常仍是一个有效响应，是否把它转成业务错误由调用方决定。
• ProtocolError 已弃用后还能用吗？ 可以用于兼容已有判断，但不要把它当成所有协议错误的唯一入口。
• 为什么要关闭 resp.Body？ 释放响应资源并帮助连接复用；即使只关心状态码，也应在确认响应非空后关闭。