Go HTTP 请求 context 取消后 Transport 会做什么

Go 里调用 cancel() 后，http.Transport 不会简单地“把所有连接关掉”。它会把请求上下文的取消信号传入本次 RoundTrip：如果请求还没有拿到响应，通常返回取消原因并关闭请求体；如果已经拿到响应，取消信号仍会影响响应体的读取。判断这件事的关键，是看取消发生在获取连接、发送请求，还是读取响应体的阶段。

把 Request.Context() 看成一次 HTTP 事务的生命周期开关最准确。取消只针对当前请求，连接池和其他请求是否继续工作由 Transport 的协议路径和连接状态决定。

下面按源码行为拆开看，示例只使用标准库，不需要调用已经废弃的 Transport.CancelRequest。

context 实际管住了哪些阶段

NewRequestWithContext 的文档把范围说得很完整：对外发请求时，context 控制获取连接、发送请求，以及读取响应头和响应体的整个生命周期。因此，下面这段代码不是只给“等待响应”加了超时：

ctx, cancel := context.WithTimeout(context.Background(), 800*time.Millisecond)
defer cancel()

// 把同一个超时边界交给整个 HTTP 请求，而不是只包住 ReadAll。
req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
if err != nil {
    return err
}

resp, err := http.DefaultClient.Do(req)
if err != nil {
    // 中文说明：主动取消和超时都应单独统计，别一律记成服务端 5xx。
    if errors.Is(err, context.DeadlineExceeded) {
        return fmt.Errorf("请求超时: %w", err)
    }
    if errors.Is(err, context.Canceled) {
        return fmt.Errorf("请求被取消: %w", err)
    }
    return err
}
defer resp.Body.Close()

// 中文说明：响应头到达后，读取响应体仍受同一个 context 约束。
body, err := io.ReadAll(resp.Body)
if err != nil {
    return fmt.Errorf("读取响应体: %w", err)
}
_ = body

所以只在 io.ReadAll 外面再套一个计时器，不能覆盖 DNS、建连、TLS、发送请求或等待响应头的时间。

Transport 取消时先做什么

进入 Transport.RoundTrip 后，标准实现会基于请求 context 派生一份传输层上下文，并把旧式 Request.Cancel、兼容用的 CancelRequest 转换到这条取消链上。主循环在继续取连接前先检查 ctx.Done()：

• 如果已经取消，Transport 关闭请求体并返回取消原因；此时通常没有 Response 可以使用。
• 如果是在拿连接、写请求或等响应时取消，RoundTrip 会结束当前请求；调用方应通过 errors.Is 判断是主动取消还是超时。
• 请求体属于 Transport 的清理责任。自定义 RoundTripper 也必须遵守“出错时关闭 Request.Body”的约定，不能把 Body 留给调用方猜测。

这解释了一个常见现象：服务端日志可能看到请求已经到达，但客户端仍然收到 context canceled。取消是客户端本地生命周期结束，不等于服务端已经回滚或完全没有执行过业务。

拿连接和真正传输不是一回事

Transport 的连接获取还有一个容易被忽略的边界：标准实现会保留请求 context 的值，但在拨号时使用不带取消信号的派生 context。这样做的意图是，当前请求即使取消，正在建立的连接仍可能被后续请求复用。于是你可能观察到：

因此，排查时要同时记录“业务调用什么时候结束”和“Transport 的连接状态怎样变化”，不要看到一次取消就调用 CloseIdleConnections。后者只关闭空闲连接，也不会中断正在使用的连接。

HTTP/1 和 HTTP/2 的观察结果为什么不同

同一个 Request.Context() 在不同协议路径上的底层动作并不完全相同。HTTP/1 路径围绕持久连接的读写循环处理取消；HTTP/2 路径在单条请求流上处理取消。两者都应让当前请求尽快结束，但不能把“当前请求取消”理解成“Transport 全部断开”。

旧的 Transport.CancelRequest 已经废弃，而且不能取消 HTTP/2 请求。新代码应使用 NewRequestWithContext 或 req.WithContext；自定义 RoundTripper 也要把 req.Context() 继续传给底层操作。

业务层怎样把取消和故障分开

最实用的判断顺序是先看 errors.Is，再看是否已经拿到响应：

resp, err := client.Do(req)
if err != nil {
    // 中文说明：这两类属于调用方生命周期事件，不应直接算成远端 5xx。
    switch {
    case errors.Is(err, context.Canceled):
        metrics.Count("http.client.canceled")
    case errors.Is(err, context.DeadlineExceeded):
        metrics.Count("http.client.timeout")
    default:
        metrics.Count("http.client.transport_error")
    }
    return err
}
defer resp.Body.Close()

// 中文说明：即使状态码是 500，RoundTrip 仍可能成功返回 Response。
if resp.StatusCode >= http.StatusInternalServerError {
    return fmt.Errorf("远端返回 %s", resp.Status)
}
return nil

RoundTripper 的职责是取得响应；HTTP 状态码不是 Transport 层错误。这样分层后，取消、超时、连接失败和服务端 5xx 才不会混在一条指标里。

自定义 RoundTripper 最容易漏掉的点

如果项目包装了 Transport，不能只把请求转发给另一个函数，却忽略 req.Context()。自定义实现至少要做到三件事：

1. 把 context 传给底层拨号、查询或 SDK 调用；
2. 在等待自有队列、重试或限流令牌时选择监听 req.Context().Done()；
3. 在返回错误或取消时关闭请求体，并确保成功返回的 Response.Body 由调用方关闭。

如果自定义 RoundTripper 完全不理会 context，Client.Do 无法替它停止任意阻塞的业务代码。此时看到“context 已取消但调用还没返回”，优先检查包装层，而不是先怀疑标准 Transport 没有生效。

排查时记住这四个结论

• 取消信号覆盖一次请求的完整生命周期，不只覆盖读响应体。
• 标准 Transport 取消时会清理请求体，并将取消原因返回给调用者。
• 取消当前请求不等于关闭整个连接池；拨号、HTTP/1 和 HTTP/2 的资源行为要分开看。
• 新代码使用 Request Context，并用 errors.Is 分类；自定义 RoundTripper 必须继续传递取消信号。

相关问题

为什么服务端收到了请求，客户端还是 context canceled？ 客户端取消只说明本地不再等待，服务端可能已经开始处理，是否停止要由服务端自己的请求 context 和业务事务决定。

取消后需要手动关闭 Transport 吗？ 一般不需要。复用的 Transport 应长期使用；只在明确要清理空闲连接时考虑 CloseIdleConnections。

为什么自定义 RoundTripper 仍然超时？ 检查它是否把 req.Context() 传给底层操作，以及是否在自有等待点监听 Done()。