Go问答：http.ProtocolError客户端遇到协议错误时怎样区分原因为什么结果为空或不符合预期

http.ProtocolError 不能作为 Go HTTP 客户端所有协议错误的统一判断入口。官方已将该类型标记为 deprecated，原因是许多协议相关错误并不使用这个类型。遇到结果为空，应分别保留请求构建、Client.Do、状态码和正文读取的错误，再用 errors.Is 与 errors.As 判断已知原因；匹配不到 ProtocolError 不等于没有协议问题。

官方文档：https://pkg.go.dev/net/http

URL错误包装说明：https://pkg.go.dev/net/url

官方能力提示：ProtocolError不能覆盖全部协议故障

这里解读的是官方现有接口合同，并非一则新版本发布新闻。实际接入时最容易出现的误区是把“协议故障”这个排障概念，等同于 *http.ProtocolError 这个历史类型。两者范围不同，不能拿单个类型判断代替错误分层。

例如客户端没有拿到完整响应、正文中途断开、请求地址与服务入口不匹配，都会表现为调用失败，但具体错误类型还受传输协议、底层连接及包装层影响。排障应保留原始错误，不靠一串固定英文子串决定全部业务分支。

适用场景：先分清失败发生在哪一层

请求责任组包含构建请求、Client.Do、响应对象；结果责任组包含状态码、正文读取、错误链。Client.Do 使用构建完成的请求，响应对象来自调用结果并包含状态码和正文读取入口，错误链承载各阶段失败。这张图解释静态依赖，不声称已经抓取任何运行链路。

Client.Do 返回错误时，常见最外层包装是 *url.Error。它提供 Unwrap，因此可以用标准错误链查询向内寻找具体原因。若 Do 返回 nil 错误，也不能立即宣布业务成功：非 2xx 状态通常不会让 Do 自动返回错误，正文也是之后才按需读取。

所以“返回内容为空”至少需要回答三件事：是否真正收到响应；状态码是否符合合同；正文读取是否完整。空正文也可能是合法响应，例如某些无正文状态或 HEAD 请求，不能不看方法与状态就归结为协议解析失败。

快速接入：保留错误链与读取阶段

示例用错误标签帮助定位，保留原始错误链，不把 other 判定为“不是协议错误”。它只读取受信任地址，限制正文到 1 MiB 并设置超时，适用于小型接口诊断；不输出响应正文。errors.Join 要求 Go 1.20 或更新版本。本文未执行程序，不提供虚构运行输出。

package main

import (
    "context"
    "errors"
    "fmt"
    "io"
    "net"
    "net/http"
    "os"
    "time"
)

// classify 给出排查标签，other 不代表已经排除协议问题。
func classify(err error) string {
    if err == nil {
        return "none"
    }
    if errors.Is(err, context.Canceled) {
        return "canceled"
    }
    if errors.Is(err, context.DeadlineExceeded) {
        return "deadline"
    }
    var pe *http.ProtocolError
    if errors.As(err, &pe) { // 穿透包装链，而不是只断言最外层。
        return "legacy-protocol-type"
    }
    var ne net.Error
    if errors.As(err, &ne) && ne.Timeout() {
        return "timeout"
    }
    return "other"
}

func fetch(ctx context.Context, client *http.Client, target string) (err error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, target, nil)
    if err != nil {
        return fmt.Errorf("构建请求: %w", err)
    }
    resp, err := client.Do(req)
    if err != nil {
        return fmt.Errorf("发送请求[%s]: %w", classify(err), err)
    }
    defer func() { err = errors.Join(err, resp.Body.Close()) }() // 保留关闭失败。
    if resp.StatusCode = 300 {
        return fmt.Errorf("HTTP状态失败: %d", resp.StatusCode)
    }
    const limit = int64(1  limit {
        return fmt.Errorf("正文超过读取上限")
    }
    return nil
}

func main() {
    if len(os.Args) != 2 {
        fmt.Fprintln(os.Stderr, "用法：程序名 受信任的HTTP地址")
        os.Exit(2)
    }
    client := &http.Client{Timeout: 5 * time.Second}
    if err := fetch(context.Background(), client, os.Args[1]); err != nil {
        fmt.Fprintln(os.Stderr, err) // 示例本地诊断；生产日志应脱敏URL及查询参数。
        os.Exit(1)
    }
}

classify 的判断顺序是诊断策略，不是互斥的数学分类。一个错误可能同时体现超时和取消条件，本文优先显示明确的 Context 信号；业务如果需要全部原因，应分别记录多个布尔属性。ProtocolError 匹配只记录“存在历史类型”，不能据此推断具体协议版本或决定可重试性。

请求已经获得响应时，Body 需要关闭。若在读取过程中发生截断等异常，必须返回读取错误，不能把已读到的部分字节当成完整结果。本例使用 LimitReader 多读一个字节识别超限，达到本地上限并不等于已确认原始正文完整；超限时明确失败并关闭资源。

与直接断言旧写法相比有什么不同

直接写 err.(*http.ProtocolError) 只检查外层动态类型，还可能在不匹配时 panic；即使使用安全的逗号 ok 形式，也会漏掉包装链中的匹配。errors.As 能沿链查找类型，但它不会把其他协议故障自动转换成 ProtocolError。

错误身份组包含errors.Is、取消超时信号；类型线索组包含errors.As、ProtocolError、net.Error；保留责任组包含原始错误链。Is 查询取消超时信号，As 查询 ProtocolError 与 net.Error，两种查询均依赖原始错误链。标签是线索，不是无损替代原始原因。

采用边界与相关问答

接入时先让错误阶段可见，再核对地址的 scheme、端口、代理配置和服务实际支持的协议。不要遇到解析错误就关闭TLS证书验证，也不要为了让请求“能发出去”盲目调整安全配置。日志中的完整错误可能带URL，生产系统应按日志策略去除口令、查询参数与敏感标识，同时保留阶段和错误类型线索。

deprecated是否意味着旧代码立即不能编译？

不意味着删除。它提醒调用者不要把这个类型当成完整分类合同。迁移重点是扩大错误处理的正确范围，而不是机械删掉所有匹配分支。

能否靠Error字符串自动重试？

不适合作为通用规则。重试还取决于方法、请求体是否可重放、服务端是否可能已处理以及业务幂等性。本文只分类诊断，不实现自动重试。

收到非2xx后需要无限读取正文吗？

不需要。是否消费错误正文应服从大小、时间和连接管理策略；本例直接返回状态失败并关闭Body，不承诺每种失败下都能复用连接。调试信息应有界读取，避免诊断本身失控。