Go CheckRedirect 返回错误时怎么读取最后一次响应

在 Go 的 HTTP 客户端里，CheckRedirect 返回错误后，调用方经常会看到一个不为 nil 的 Response，于是顺手读取 resp.Body，结果不是读不到内容，就是把重定向策略错误和响应状态混在一起。

关键区别只有一句：普通错误返回时，返回的响应体已经关闭；如果希望停在当前跳转并读取最后一次响应，应该在 CheckRedirect 中返回 http.ErrUseLastResponse。这个特殊返回会让客户端返回最近一次响应，同时把错误置为 nil，并保留可读取的 Body。

Go CheckRedirect 的错误返回到底保留了什么

CheckRedirect 的 req 是准备发送的下一次请求，via 是已经发出的请求列表，顺序从最早的一次开始。它不是最后一个 Response 的参数，所以不要试图从回调直接读取响应体。

当回调返回普通错误时，Client.Get 或 Client.Do 会返回上一跳的 Response 和一个包装后的 *url.Error。这个 Response 的状态码、Header、Request 等元数据仍有记录价值，但官方实现会关闭它的 Body。下面这个判断可以记录跳转证据，却不应该调用 io.ReadAll(resp.Body)：

client := &http.Client{
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        // 只允许一次跳转，避免继续访问未信任的目标。
        if len(via) >= 1 {
            return fmt.Errorf("redirect blocked: %s", req.URL.String())
        }
        return nil
    },
}

resp, err := client.Get(startURL)
if err != nil {
    // 普通 CheckRedirect 错误下，resp 可能非空，但 Body 已关闭。
    var urlErr *url.Error
    if errors.As(err, &urlErr) {
        log.Printf("redirect error: op=%s url=%s", urlErr.Op, urlErr.URL)
    }
    if resp != nil {
        log.Printf("last status=%s location=%s", resp.Status, resp.Header.Get("Location"))
    }
    return
}
defer resp.Body.Close()

这里的“最后一次响应”更准确地说是最后一次响应的元数据，而不是可消费的响应内容。非 2xx 状态本身也不会自动变成 Go error，只有客户端策略、协议或网络层失败才会进入 err。

需要保留响应体时返回 ErrUseLastResponse

如果需求是读取 301、302 或其他重定向响应的正文，例如解析服务端返回的提示 JSON，就不要返回自定义错误，而是返回 http.ErrUseLastResponse。这是 net/http 约定的特殊信号：不发送下一次请求，返回最近一次 Response，且 err == nil，Body 保持打开。

client := &http.Client{
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        // 停在当前 3xx 响应，让调用方读取它的 Body。
        return http.ErrUseLastResponse
    },
}

resp, err := client.Get(startURL)
if err != nil {
    return fmt.Errorf("request redirect response: %w", err)
}
defer resp.Body.Close()

body, err := io.ReadAll(io.LimitReader(resp.Body, 1

这条分支的资源责任转移给调用方：必须读取或至少处理 Body，并最终关闭它。若只想查看状态码和 Location，也可以立即关闭 Body，不要因为它是 3xx 就把响应体长期留着。

既要自定义错误又要记录最后一次响应怎么办

自定义错误和可读取 Body 是两个不同的语义。前者会触发客户端关闭上一跳 Body，后者要求使用 ErrUseLastResponse 并放弃通过返回值传递错误。生产代码通常在回调闭包中保存需要审计的元数据，再返回自定义错误：

var redirectAudit struct {
    from, to string
    status    int
}

client := &http.Client{
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        // via 的最后一项是当前跳转前最近一次请求。
        if len(via) > 0 {
            redirectAudit.from = via[len(via)-1].URL.String()
        }
        redirectAudit.to = req.URL.String()
        // 回调没有 Response，只能保存请求侧信息。
        return errors.New("redirect policy denied")
    },
}

resp, err := client.Get(startURL)
if err != nil {
    // 这里读取审计字段；不要读取 resp.Body。
    log.Printf("redirect denied from=%s to=%s", redirectAudit.from, redirectAudit.to)
}
if resp != nil {
    redirectAudit.status = resp.StatusCode
}

需要注意并发：上面的闭包变量只适合单次请求演示。共享的 http.Client 可以并发使用时，应为每次请求创建独立的审计对象，或用带锁的结构保存，避免不同请求互相覆盖。

用判断表收口重定向错误处理

落地时可以按下面的顺序检查：第一，是否真的要读取 3xx 正文；要读就返回 ErrUseLastResponse。第二，是否要保留业务错误；要保留就记录回调里的请求信息，并把返回 Response 当作已关闭资源。第三，是否可能跨域；重定向到不同主机时，不要默认把 Authorization 等敏感 Header 带过去，必要时在回调里检查目标 URL。

最后不要用 len(via) 当作“响应次数”的唯一业务证据。它表示已经发出的请求数量，而不是可以读取的响应数量。日志里同时记录起始 URL、目标 URL、via 长度、状态码和错误类型，排查时会比只打印一条“redirect failed”可靠得多。

常见问题

CheckRedirect 返回 error 后 resp 一定是 nil 吗？

不一定。CheckRedirect 失败是少数会同时返回 Response 和 error 的情况，但该 Response 的 Body 已关闭，通常只用于状态码和 Header 等元数据。

ErrUseLastResponse 返回后还需要关闭 Body 吗？

需要。它只是让 Body 保持未关闭并把最后一次响应交给调用方，读取完成后仍应调用 Close。

只是不想跟随重定向，能不能返回 errors.New？

可以，但那是“策略失败”语义，不能再读取返回响应体。只想保留 3xx 响应供后续处理时，应返回 http.ErrUseLastResponse。