Go HTTP 请求返回 EOF 怎样区分服务端关闭和解析失败

Go HTTP 请求遇到 EOF，不能只看错误字符串就断定“服务端主动关闭了连接”。先看它出现在哪一步：http.Client.Do 返回错误，通常是请求还没有拿到可用响应；Response.Body 读取阶段出错，说明响应已经开始交付但传输没有完整结束；json.Decoder.Decode 返回 io.EOF，则常见于正文为空或流已经正常读完。JSON 在结构中途结束时，更应该关注 io.ErrUnexpectedEOF 或 *json.SyntaxError。

下面按“请求建立、响应读取、内容解析”三层拆开判断。这样即使最终都显示为 EOF，日志也能保留真正的故障位置。

先确定 EOF 出现在哪一层

Client.Do 负责拿到响应头；响应正文是后续读取 resp.Body 时才开始流式交付。若 Do 直接报错，先检查网络、代理、TLS、重定向策略和服务端是否在发送响应头前断开。此时不要继续使用一个带错误的响应对象。

如果 Do 成功，说明至少拿到了响应头，接着要把读取和解析分开。io.ReadAll 会把正常的 EOF 视为读取结束并返回成功；若响应声明了更长内容却提前断开，常见结果是 io.ErrUnexpectedEOF。最后，JSON 解码器面对空输入会返回 io.EOF，而半截 JSON 往往会返回意外结束或语法错误。

读取响应前先保留 HTTP 上下文

不要把所有错误都包装成“JSON 解析失败”。先记录状态码、响应头和读取阶段，再决定是否进入解码。非 2xx 本身不会让 Client.Do 返回 error，服务端可能用 HTML 或空正文返回错误页面；如果直接交给 JSON 解码，日志就会把业务状态误写成内容格式问题。

// 先区分 HTTP 状态与正文解析，避免把 500 页面误判成 JSON 错误。
if resp.StatusCode = 300 {
    return fmt.Errorf("http status=%d", resp.StatusCode)
}

// Body 必须关闭；读取阶段的错误要保留原始原因。
raw, err := io.ReadAll(resp.Body)
if err != nil {
    return fmt.Errorf("读取响应正文失败: %w", err)
}

这里的关键不是把 EOF 改成更长的文字，而是保留“状态码 + 阶段 + 原始错误”。同时要始终关闭 resp.Body，否则连接复用和后续请求排查都会受到影响。

用空正文和截断正文分别处理

空正文是一个业务边界，不等于服务端一定异常。例如 204 响应可能本来就没有内容；而接口契约要求 JSON 时，空正文应该报告为“响应为空”，让调用方决定是否允许。对已经读到部分字节的正文，如果传输提前结束，优先记录已读字节数和 Content-Length，不要只记录一个 EOF。

// 这是内容层判断：空白正文不能直接当成合法 JSON 对象。
if len(bytes.TrimSpace(raw)) == 0 {
    return fmt.Errorf("响应正文为空: %w", io.EOF)
}

// 解析错误与网络读取错误分开记录，方便重试策略按原因决策。
if err := json.Unmarshal(raw, out); err != nil {
    var syntaxErr *json.SyntaxError
    if errors.As(err, &syntaxErr) {
        return fmt.Errorf("JSON 语法错误，offset=%d: %w", syntaxErr.Offset, err)
    }
    return fmt.Errorf("JSON 内容解析失败: %w", err)
}

json.Unmarshal 适合已经完整读入内存的响应；如果是持续 JSON 流，则使用 json.Decoder，并把“流正常结束”和“对象中途被截断”分开处理。无论选哪一种，解析错误都应该带上响应状态或请求标识，便于和传输层日志关联。

封装带阶段信息的错误

下面的封装把三类故障固定成可检索的前缀。请求阶段的 EOF 更接近“还没拿到完整响应”；读取阶段的意外 EOF 更接近“响应交付不完整”；解析阶段的 EOF 则需要结合接口契约判断空响应是否允许。

// fetchJSON 只负责划分错误阶段，不把 EOF 武断归因给某一方。
func fetchJSON(ctx context.Context, client *http.Client, endpoint string, out any) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
    if err != nil {
        return fmt.Errorf("请求构造阶段失败: %w", err)
    }

    resp, err := client.Do(req)
    if err != nil {
        // Do 失败时通常没有可用响应；保留 url.Error 等包装信息。
        return fmt.Errorf("请求建立阶段失败: %w", err)
    }
    defer resp.Body.Close()

    if resp.StatusCode = 300 {
        return fmt.Errorf("HTTP 响应状态异常: %s", resp.Status)
    }

    raw, err := io.ReadAll(resp.Body)
    if err != nil {
        return fmt.Errorf("响应读取阶段失败: %w", err)
    }
    if len(bytes.TrimSpace(raw)) == 0 {
        return fmt.Errorf("响应解析阶段为空正文: %w", io.EOF)
    }
    if err := json.Unmarshal(raw, out); err != nil {
        return fmt.Errorf("响应解析阶段失败: %w", err)
    }
    return nil
}

生产日志建议再加上请求方法、URL 的安全标识、状态码、读取字节数和重试次数。不要把完整响应正文、认证信息或敏感查询参数直接写入日志。

回归检查：五种输入都要有明确结论

最终可以记住一句话：EOF 只是信号，不是根因。先看错误来自 Do、Body.Read 还是 JSON 解码，再结合状态码、正文长度和接口契约判断是服务端关闭、链路中断、空响应还是解析失败。

相关问题

为什么非 2xx 不会自动进入 error？因为 HTTP 层已经成功收到响应，状态码属于应用判断，调用方需要自行决定是否接受。

为什么读取 Body 后还要关闭？关闭响应体是客户端的资源责任，也关系到底层连接是否能被复用。

空响应应该重试吗？不能仅凭 EOF 决定。先看状态码和接口契约；若请求有副作用，更不能把不确定结果直接当成可安全重试。

官方依据：https://pkg.go.dev/net/http、https://pkg.go.dev/io、https://pkg.go.dev/encoding/json