Go HTTP 请求一直卡住怎么办：从默认客户端到超时控制一步步排查

Go 服务里调用第三方 HTTP 接口很常见，但线上最怕一种问题：代码看起来没有报错，请求却越积越多，接口延迟慢慢被拖高。我们这篇不直接背参数，而是从一个“请求一直卡住”的现象开始，一步一步确认原因，再把超时控制写成可复用的方式。

本文适合已经会写 Go HTTP 请求，但还没有系统处理超时、取消和资源释放的读者。示例基于 Go 标准库 net/http 和 context。

目录

• 问题现场：接口没有报错，但请求一直不回来
• 先复现现象：默认 HTTP 客户端可能一直等
• 初步判断：问题不是语法，而是缺少等待边界
• 修复方案：给请求设置明确截止时间
• 最后验证：慢接口能被及时打断
• 容易踩坑的细节
• 总结清单

问题现场：接口没有报错，但请求一直不回来

先看一个很常见的写法。为了方便复现，我们用 httptest 模拟一个 5 秒后才返回的慢接口，然后用默认客户端去请求它：

package main

import (
    "fmt"
    "net/http"
    "net/http/httptest"
    "time"
)

func main() {
    slowAPI := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        time.Sleep(5 * time.Second)
        fmt.Fprintln(w, "ok")
    }))
    defer slowAPI.Close()

    start := time.Now()
    resp, err := http.DefaultClient.Get(slowAPI.URL)
    fmt.Println("cost:", time.Since(start), "err:", err)
    if resp != nil {
        _ = resp.Body.Close()
    }
}

运行后会发现，它并不会很快失败，而是老老实实等慢接口返回。在线上场景里，如果上游接口卡住更久，调用方也会被拖着等。请求量一上来，等待中的 goroutine、连接和业务队列就会堆起来。

先复现现象：默认 HTTP 客户端可能一直等

这一步我们先不急着改代码，只确认现象链路：Go 服务发起请求，默认客户端把请求交给慢接口，慢接口迟迟不返回，调用方就持续等待。

图里的关键点是“默认客户端”和“等待堆积”。默认客户端不是不能用，而是它没有替你的业务决定“最多等多久”。如果业务接口希望 2 秒内返回，那这个边界必须由我们自己写出来。

初步判断：问题不是语法，而是缺少等待边界

我们先做一个猜测：这不是 Go HTTP 包坏了，也不是 goroutine 自己泄漏，而是请求没有明确的停止条件。

验证这个猜测很简单：同一个慢接口，我们只改客户端超时时间。如果设置 1 秒超时，请求就应该在 1 秒左右返回错误，而不是继续等满 5 秒。

client := &http.Client{
    Timeout: 1 * time.Second,
}

start := time.Now()
resp, err := client.Get(slowAPI.URL)
fmt.Println("cost:", time.Since(start), "err:", err)
if resp != nil {
    _ = resp.Body.Close()
}

这时结果会接近下面这样：

cost: 1.001s err: Get "http://127.0.0.1:xxxxx": context deadline exceeded

这一步说明：问题可以通过“给请求设置明确截止时间”控制住。继续等不是唯一选择，我们可以让调用方在合理时间内拿到失败信号，然后走重试、降级或直接返回。

修复方案：给请求设置明确截止时间

修复时可以从两个层面入手：一个是客户端级别的总超时，另一个是单次请求级别的 context 截止时间。两者都不是装饰参数，而是业务稳定性的边界。

方案一：给 http.Client 设置总超时

如果某个调用方所有请求都应该有统一上限，可以直接配置 http.Client.Timeout。它覆盖连接、重定向、读取响应体等整体等待时间。

func newHTTPClient() *http.Client {
    return &http.Client{
        Timeout: 3 * time.Second,
    }
}

这种写法适合简单业务，也适合做项目里的默认客户端。注意不要每次请求都临时创建大量客户端，常见做法是复用一个配置好的客户端实例。

方案二：给单次请求设置 context 截止时间

如果不同接口的等待上限不同，或者一次业务链路里多个步骤共用同一个截止时间，context.WithTimeout 更灵活：

func callAPI(client *http.Client, url string) error {
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()

    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return err
    }

    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    if resp.StatusCode >= 500 {
        return fmt.Errorf("remote status: %d", resp.StatusCode)
    }
    return nil
}

这里有两个细节值得注意：

• defer cancel() 要保留，它能及时释放和这个上下文相关的资源。
• client.Do(req) 返回错误后，不要只打印日志就吞掉，调用方需要知道这是超时、网络失败还是远端返回异常。

最后验证：慢接口能被及时打断

修复后再跑慢接口测试，期望结果不是“永远成功”，而是“在约定时间内成功或失败”。稳定系统关注的是边界清晰，而不是盲目等待。

到这里，我们可以定位到根因：默认请求没有业务级等待边界。修复不是“把超时写得很短”，而是根据接口 SLA、调用链长度和用户可接受等待时间，设置合理的截止时间。

容易踩坑的细节

• 只设置连接超时还不够：连接成功后，读取响应也可能慢。简单场景优先用 http.Client.Timeout 控整体。
• 不要忘记关闭响应体：只要 resp 不为空，就应该关闭 resp.Body，否则连接复用会受影响。
• 不要把所有接口都配同一个超短时间：支付、上传、搜索、内部查询的等待边界可能不同，需要按业务拆分。
• 错误要向上传递：超时错误是业务信号，调用方可以用它决定重试、降级或提示用户稍后再试。

总结清单

这次排查的路径可以复用到很多 Go 外部调用场景：

1. 先复现慢接口，确认请求是否会长时间等待。
2. 检查是否使用了没有超时边界的默认客户端。
3. 简单统一场景使用 http.Client.Timeout。
4. 单次请求或链路级控制使用 context.WithTimeout。
5. 保留 cancel()、关闭响应体，并把错误交给上层处理。

Go 的 HTTP 调用并不复杂，真正容易漏的是“最多等多久”这个业务问题。把等待边界写清楚，慢接口就不会悄悄把整个服务拖住。