Go 客户端偶发 EOF 如何判断服务端提前关闭

Go 客户端看到 EOF，第一反应不应该是“服务端一定提前关闭”。io.EOF 本来就是 Reader 表示“没有更多输入”的正常结束信号；真正需要排查的是：响应头已经收到后，响应体是否在预期边界之前被截断。判断时把 HTTP 状态、Content-Length、实际读取字节数、错误类型和服务端日志放在一起看，结论会比单看一行错误可靠。

官方地址：https://pkg.go.dev/io

先确认错误发生在 Client.Do 还是 Response.Body 读取阶段，再比较“应该收到多少”和“实际收到多少”。只有证据表明响应不完整时，才把它归类为服务端或中间链路提前结束。

先区分响应头成功与响应体读取失败

http.Client.Do 返回 nil 错误，只说明客户端已经拿到可用的响应对象，并不代表响应体的全部字节都已经到达。响应体是按需读取的流，网络连接失败或服务端终止响应时，后续的 Body.Read 仍可能返回错误。相反，非 2xx 状态码本身也不会让 Do 返回错误。

因此先把错误发生位置记录清楚：

resp, err := client.Do(req)
if err != nil {
    // 这里是请求阶段失败，通常没有可用的响应体可以继续分析。
    return fmt.Errorf("发送请求失败: %w", err)
}
defer resp.Body.Close() // 无论后续读取是否成功，都要释放响应体。

body, err := io.ReadAll(resp.Body)
if err != nil {
    // 这里才是响应头已收到、响应体读取阶段失败。
    return fmt.Errorf("读取响应体失败: status=%s: %w", resp.Status, err)
}
_ = body // 业务代码在这里解析或交给下一层处理。

io.ReadAll 会把正常的 EOF 当作读取完成并返回 nil；如果它返回错误，才需要继续分析截断、超时、取消或协议错误。若直接调用 Read，读到结尾返回 io.EOF 也可能是正常情况，不能把 EOF 这个词单独当成根因。

用读取位置判断是不是提前关闭

最有价值的线索是“协议声称的长度”和“客户端实际收到的长度”。如果响应带有明确的 Content-Length，可以先记录该值；实际字节数少于它时，响应很可能没有完整到达。若响应使用分块传输或压缩，不能简单拿压缩前后的业务长度相减，要把判断交给 HTTP 传输层和上层格式解析结果。

func readBody(resp *http.Response) ([]byte, error) {
    defer resp.Body.Close() // 关闭由本函数取得的响应体，避免连接资源遗留。

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        // 记录已读字节和声明长度，方便与服务端日志按请求 ID 对照。
        return nil, fmt.Errorf("body read: status=%d content_length=%d got=%d: %w",
            resp.StatusCode, resp.ContentLength, len(body), err)
    }
    if resp.ContentLength >= 0 && int64(len(body)) != resp.ContentLength {
        // 长度不一致时不要把响应交给 JSON 或业务层继续处理。
        return nil, fmt.Errorf("body truncated: want=%d got=%d",
            resp.ContentLength, len(body))
    }
    return body, nil
}

结构化数据还要看解析器给出的错误。固定长度块或 JSON 在中途遇到结束，常见的是 io.ErrUnexpectedEOF 或解析器自己的语法错误；这比一个普通 EOF 更能说明“数据结构尚未完整”。如果读取超时、请求上下文被取消或连接被本地关闭，错误包装中通常会留下不同的线索，所以不要只用字符串包含判断。

可以把证据整理成一张小表：

让 EOF 错误能够安全重试

EOF 只说明这一次读取没有按预期完成，不自动说明重试一定成功。重试前至少确认三件事：请求方法和业务操作是否幂等、请求体是否能够重新创建、服务端是否可能已经完成了副作用。GET、HEAD 这类读取请求通常更容易设计有限重试；支付、创建订单或重复写入请求不能因为看到 EOF 就直接重放。

func getWithRetry(ctx context.Context, client *http.Client, url string) ([]byte, error) {
    for attempt := 0; attempt 

示例中的两个判断函数应根据业务错误模型实现，不能把所有包含 EOF 的字符串都归入可重试。生产日志至少带上请求 ID、目标主机、尝试次数、状态码、声明长度、已读字节和耗时；敏感请求体不要为了排障直接打进日志。

把客户端证据和服务端日志对上

确认“服务端提前关闭”不能只靠客户端猜测。客户端记录请求 ID 和精确时间窗口，服务端按同一 ID 查处理函数是否提前返回、连接是否在写完响应前关闭、代理是否报告上游重置，以及响应是否经过压缩或分块。若服务端日志显示业务处理已经成功，但客户端只收到半段响应，还要继续看网关、负载均衡和连接复用层；不要立即把责任归给业务 Handler。

最后按这条顺序收敛问题：

1. 先看错误在 Do 还是 Body.Read，再看 HTTP 状态是否只是非 2xx。
2. 对有长度边界的响应比较声明长度和已读字节，对结构化内容保留解析错误。
3. 用请求 ID、尝试次数和时间窗口查询服务端及中间代理日志。
4. 只有幂等、可重建且副作用边界清楚时才做一次有限重试。

这样处理后，“偶发 EOF”会从模糊的网络现象变成可对照的证据链：正常结束、响应截断、请求阶段失败和业务解析失败各自有不同处置方式。

常见问题

为什么日志里出现 EOF，但请求其实成功了？

直接读取 io.Reader 时，EOF 就是正常结束信号；如果 io.ReadAll 已经返回 nil 且业务解析成功，不要把这条内部结束信号当成异常。

Content-Length 不匹配就一定是服务端代码问题吗？

不一定。服务端、反向代理、压缩层和连接中断都可能造成不完整响应。客户端只能先确认边界不完整，再用请求 ID 和时间窗口把责任定位到具体链路。