Go context HTTP 超时 请求取消后为何仍占资源

Go 里给 HTTP 请求加上 context.WithTimeout，只能保证取消信号沿着请求链路传播；它不会替调用方关闭已经拿到的 Response.Body，也不会强制终止一个完全不监听 context 的业务 goroutine。请求超时后仍看到连接、响应体或 goroutine 占用资源，通常是清理职责没有落到对应对象上。

处理原则可以先记成一句话：请求开始前绑定 context，调用结束后释放 cancel；拿到非空响应后关闭 Body，确实需要连接复用时再有限度读取剩余内容；自定义工作则必须主动监听 Done。

先看清：取消的是工作信号，不是所有资源

context.Context 负责携带截止时间、取消信号和请求范围的数据。WithTimeout 返回派生 context 与 cancel 函数，超时或主动调用 cancel 后，Done() 会关闭，Err() 通常能区分 context.DeadlineExceeded 和 context.Canceled。

HTTP 客户端通过 http.NewRequestWithContext 或 req.WithContext 读取这个信号。网络传输层能够据此停止正在进行的请求，但已经交给调用方的 Response.Body 仍然由调用方负责关闭。相反，自己启动的重试循环、解码 goroutine 或回调函数，如果没有选择监听 ctx.Done()，也不会因为 context 被取消就自动消失。

正确的最小写法：超时、请求和响应分层处理

下面的代码只覆盖一次 HTTP 调用。重点不在“把所有逻辑塞进一个超时”，而在于每个返回路径都明确谁负责清理。

package main

import (
    "context"
    "errors"
    "fmt"
    "io"
    "net/http"
    "time"
)

func fetch(ctx context.Context, client *http.Client, url string) error {
    // 派生超时 context，并在函数返回时释放定时器等关联资源。
    reqCtx, cancel := context.WithTimeout(ctx, 800*time.Millisecond)
    defer cancel()

    // 把同一个 context 绑定到请求，Transport 才能收到取消信号。
    req, err := http.NewRequestWithContext(reqCtx, http.MethodGet, url, nil)
    if err != nil {
        return fmt.Errorf("创建请求失败: %w", err)
    }

    resp, err := client.Do(req)
    if err != nil {
        // Do 出错时通常没有可供关闭的响应体，先判断错误类型再返回。
        if errors.Is(err, context.DeadlineExceeded) {
            return fmt.Errorf("请求超时: %w", err)
        }
        return fmt.Errorf("请求失败: %w", err)
    }
    // Do 已返回非空响应后，Body 的关闭责任转移给调用方。
    defer resp.Body.Close()

    // 示例只需要确认响应能被消费；生产代码应按协议解码并检查状态码。
    if _, err := io.Copy(io.Discard, resp.Body); err != nil {
        return fmt.Errorf("读取响应体失败: %w", err)
    }
    if resp.StatusCode = http.StatusMultipleChoices {
        return fmt.Errorf("远端返回状态码 %d", resp.StatusCode)
    }
    return nil
}

这里有三个容易漏掉的点：第一，cancel 释放的是派生 context 的计时器等资源；第二，只有 resp 非空时才安排 Body.Close；第三，关闭响应体不等于业务逻辑一定成功，状态码和读取错误仍需要单独处理。

为什么只调用 cancel，资源看起来还在

最常见的误会是把下面四个对象当成同一个资源：context 的计时器、HTTP Transport 的连接、Response.Body 的读取状态、业务代码创建的 goroutine。它们的生命周期不同，所以取消后观察到短暂占用并不必然表示 context 失效。

此外，HTTP 连接是否能够复用与响应体是否被正确消费有关。若业务只需要丢弃一个小响应，可以有限度读取后关闭；如果响应体很大或服务端持续输出，则不要为了“复用连接”无限等待，应让超时和关闭优先。

需要连接复用时，给读取设置上限

在代理、探活或批量请求中，常见做法是读取有限大小的剩余响应，再关闭 Body。这样既避免把未知大小的响应全部读入内存，也给 Transport 一个结束当前响应的机会。

func drainAndClose(resp *http.Response, limit int64) error {
    if resp == nil || resp.Body == nil {
        return nil
    }
    // 只读取有限字节，避免异常大的响应拖住调用方。
    if limit > 0 {
        if _, err := io.Copy(io.Discard, io.LimitReader(resp.Body, limit)); err != nil {
            _ = resp.Body.Close()
            return fmt.Errorf("有限读取响应体失败: %w", err)
        }
    }
    // 无论读取是否达到上限，最终都要关闭 Body。
    return resp.Body.Close()
}

这个辅助函数不是所有请求的固定模板。若响应体是下载内容，应交给文件或流式消费者处理；若接口返回 JSON，应在解码完成后关闭；若请求已经因为 context 取消而返回错误，则不要假设一定存在可关闭的 Response。

取消后仍占资源的排查顺序

1. 确认请求真的绑定了派生 context。检查是否把 reqCtx 传给了 NewRequestWithContext，而不是只在外层创建了一个从未被请求使用的 context。
2. 确认错误路径没有继续等待。调用 client.Do 返回错误后直接进入重试、解码或发送结果的代码，可能让业务 goroutine 自己继续占用资源。
3. 确认非空响应一定关闭。哪怕状态码是 500，也可能已经拿到了可读的 Response；要先关闭 Body，再决定是否重试。
4. 确认自定义 RoundTripper 遵守 Request.Context。如果自定义传输层内部阻塞在不可取消的系统调用或第三方库里，外层 cancel 只能发出信号，不能替它实现取消。
5. 确认 goroutine 有退出分支。网络调用之外的处理应使用 select 同时等待业务结果与 ctx.Done()，并在退出前关闭自己的 channel、文件或 ticker。

func waitResult(ctx context.Context, result 

最后总结

Go HTTP 超时后仍占资源，优先检查的不是“要不要再调用一次 cancel”，而是生命周期是否闭合：请求是否使用了正确的 context，client.Do 返回的 Response 是否被关闭，响应体是否被无界读取，自定义传输层和业务 goroutine 是否真正监听取消信号。把这几层职责拆开后，超时只会停止它有能力停止的工作，剩余对象也会由明确的所有者完成清理。

相关问题

• context.WithTimeout 一定能终止 HTTP 服务端正在执行的业务吗？不能保证。它主要控制客户端请求链路；服务端是否停止自己的处理取决于服务端是否读取并响应自己的 Request.Context。
• Response.Body 关闭后还需要调用 cancel 吗？需要。关闭 Body 与释放派生 context 的计时器是两件事，二者分别由 Body.Close 和 cancel 负责。
• 为什么不能用 Transport.CancelRequest 代替 context？它已经是旧式接口，且对 HTTP/2 不能提供可靠的取消语义。新代码应使用 Request.Context。