Go 客户端为什么响应体读不到

我排查 Go HTTP 客户端的“响应体读不到”时，最先做的不是换解码器，而是把 err、HTTP 状态码和 resp.Body 分开看。很多时候请求根本没有拿到可读响应；另一些时候 Body 已经被日志代码消费过，第二次读取自然只剩 EOF。把这几个边界分清，问题通常很快就能落到具体一行。

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

先把 err、Response 和 Body 分开看

我见过最多的写法是直接判断 resp.Body，甚至在 err != nil 时继续访问 resp.StatusCode。这会把“请求失败”和“服务器返回了空内容”混成一个问题。对 http.Client.Do 来说，网络通信失败、请求构造失败或重定向策略拒绝时，应该先处理 err；当 err == nil 时，响应对象才是正常的读取入口。

另一个容易误判的点是状态码。服务器返回 404、500 或其他非 2xx 状态，仍然可能带有可读取的错误说明，它不会自动变成 Go error。先保留状态码，再决定把 Body 当作成功 JSON、错误 JSON 还是普通文本，排查信息会完整很多。

最小配方：成功拿到响应后马上安排 Close

拿到响应后，最小可靠配方是先处理错误，再安排关闭 Body，最后检查读取错误。defer 放在成功分支里，不会把一个不存在的响应体当成正常资源。

package main

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

func readText(client *http.Client, url string) ([]byte, int, error) {
    resp, err := client.Get(url)
    if err != nil {
        // 网络失败、协议失败或重定向策略失败时，先返回原始错误。
        return nil, 0, err
    }
    defer resp.Body.Close() // 成功拿到响应后立刻登记资源清理。

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        // 已经读到的字节也可能不完整，不能把读取错误悄悄吞掉。
        return body, resp.StatusCode, fmt.Errorf("读取响应体失败: %w", err)
    }
    // 状态码和正文分别返回，调用方可以独立处理业务错误。
    return body, resp.StatusCode, nil
}

这里的关键不是 io.ReadAll 这一个函数，而是返回值的分层：body 负责内容，StatusCode 负责 HTTP 结果，error 负责传输或读取过程。不要只写 body, _ := io.ReadAll(resp.Body)，否则服务端提前断开时，日志里会留下看似完整但实际被截断的内容。

Body 读过一次后为什么再解码会得到 EOF

响应体实现的是读取接口，不是可以随意回放的字符串。比如中间件先用 io.ReadAll 打日志，后面的 json.Decoder 再从原来的 Body 读取，就会看到空输入或 EOF。这不是 JSON 解码器坏了，而是输入游标已经到了末尾。

如果既要保存原文又要解码，我会先把字节存下来，再用 bytes.NewReader 创建一个新的读取器。这样日志、调试和业务解码都围绕同一份字节工作，不会让某个读取动作悄悄改变后续结果。

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
)

type userReply struct {
    ID   int    `json:"id"`
    Name string `json:"name"`
}

func readJSON(resp *http.Response) (userReply, []byte, error) {
    defer resp.Body.Close() // 函数拥有响应体的读取责任，所以在这里统一关闭。

    raw, err := io.ReadAll(resp.Body)
    if err != nil {
        // 返回原始字节便于记录截断内容，同时保留读取错误。
        return userReply{}, raw, fmt.Errorf("读取 JSON 原文失败: %w", err)
    }

    var result userReply
    decoder := json.NewDecoder(bytes.NewReader(raw))
    if err := decoder.Decode(&result); err != nil {
        // 用新的 Reader 解码，避免再次读取已经耗尽的 Response.Body。
        return userReply{}, raw, fmt.Errorf("解码响应体失败: %w", err)
    }
    return result, raw, nil
}

如果响应可能是空内容，就不要无条件把它当成 JSON。可以先看 resp.StatusCode、Content-Type 和 len(raw)，再决定是否解码；对一个本来就没有正文的响应，读到 EOF 或空字节可能正是协议语义，而不是客户端故障。

几个看起来像“读不到”的边界

我通常会把一条排查日志固定成“状态码、Content-Type、读取字节数、读取错误”四项，而不是只打印 string(body)。这样能立刻看出是服务器真的返回空内容，还是读取动作没有成功完成。若用了请求上下文，还要把超时和取消错误保留下来，避免把主动取消误报成服务端返回空字符串。

把读取逻辑收成一个可复用入口

生产代码还可以给响应体加一个上限，防止错误页面或异常代理返回过大的内容。下面的函数不替调用方决定哪些状态码算成功，只负责安全地读取、关闭并返回必要信息。

package main

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

func readResponse(resp *http.Response, maxBytes int64) ([]byte, error) {
    if resp == nil || resp.Body == nil {
        // 没有响应对象时返回明确错误，不让调用方对 nil 做猜测。
        return nil, fmt.Errorf("响应体不存在")
    }
    defer resp.Body.Close() // 无论后续读取是否报错，都释放响应体。

    limited := io.LimitReader(resp.Body, maxBytes)
    body, err := io.ReadAll(limited)
    if err != nil {
        return body, fmt.Errorf("读取响应体失败: %w", err)
    }
    return body, nil
}

LimitReader 只限制当前读取返回的字节数量，不会替你判断内容是否被截断；如果业务需要严格区分“刚好读完”和“超过上限”，可以把上限设为 maxBytes+1，读完后再检查长度。无论是否限制大小，调用方都应该保留 HTTP 状态码，不要把“读取成功”误解成“业务成功”。

常见问题

为什么 http.Get 没有 error，Body 却是空的？

没有 error 只说明 HTTP 事务拿到了响应，不代表响应一定带业务正文。先看状态码、请求方法和接口约定，再判断空 Body 是否异常。

把 resp.Body.Close() 放在读取前会怎样？

关闭后再读通常会得到读取错误或空结果。正确位置是成功拿到响应后立刻 defer，但真正的读取操作仍要发生在函数返回前。

为什么打印过响应体后 JSON 解码失败？

打印过程很可能已经消费了 Body。把原文读到 []byte 后，用 bytes.NewReader 创建新的输入交给解码器，不要再次直接读原来的 Body。