Go HTTP 请求取消后任务会自动停吗：context 传递、超时和资源释放

用户关掉页面、切走页面、或者手机网络断开之后，Go 的 HTTP 请求上下文确实会收到取消信号，但这不等于服务端所有慢任务都会自动停止。真正生效的前提是你把 r.Context() 一路透传给数据库查询、下游 HTTP 调用、消息消费逻辑，还有自己手动启动的协程。只在 handler 里读一次 ctx.Done() 远远不够，取消信号得沿着整个调用链传下去，才能把「用户已经离开」这个事件转换成「尽快终止等待、释放占有的资源」的实际动作。

浏览器断开后，Go 标准库只会发出取消信号

很多刚接触这个问题的开发者，会直接把「请求断开」和「任务停止」划等号。Go 标准库能做的只是在请求生命周期结束时取消 r.Context()，但它不会强制杀掉你后续启动的所有业务逻辑。数据库驱动、HTTP client、队列消费者、业务自定义 goroutine 会不会停下来，完全取决于它们有没有拿到同一个 context 实例。

下面这段 handler 虽然能感知用户离开的事件，但如果后续的慢任务没有实际用到 ctx，还是会继续在后台跑：

func handler(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()

    go slowTask(ctx)

    select {
    case 

这段代码看起来已经做了取消信号监听，问题出在 slowTask 的内部实现里。如果它内部执行的是不带 context 的数据库查询，或是没有设置超时的 HTTP 调用，哪怕 handler 已经返回，慢任务还是会继续占用连接、goroutine 和内存资源。

把 ctx 透传到数据库和下游调用链路

正确的做法是让请求级别的 context 一路传递到真正产生耗时的逻辑里。数据库查询优先选用带 context 参数的方法，下游 HTTP 请求也要基于当前请求的 context 来派生新的请求。这样用户离开、请求超时或者服务端主动触发取消时，整条等待链上的所有操作都有机会及时终止。

func getUser(w http.ResponseWriter, r *http.Request) {
    ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)
    defer cancel()

    id := r.URL.Query().Get("id")

    user, err := queryUser(ctx, id)
    if err != nil {
        http.Error(w, err.Error(), http.StatusGatewayTimeout)
        return
    }

    fmt.Fprintf(w, "user=%s", user.Name)
}

func queryUser(ctx context.Context, id string) (User, error) {
    row := db.QueryRowContext(ctx,
        "SELECT id, name FROM users WHERE id = ?",
        id,
    )

    var u User
    if err := row.Scan(&u.ID, &u.Name); err != nil {
        return User{}, err
    }
    return u, nil
}

这里有两个容易忽略的细节。第一，context.WithTimeout 不是用来替代 r.Context() 的，而是在它之上额外加一层服务端自身的耗时预算；第二，defer cancel() 绝对不能省略，它可以让 timer 这类内部资源及时释放，避免不必要的内存泄漏。

下游 HTTP 调用的处理逻辑也类似：

func callProfile(ctx context.Context, userID string) (*http.Response, error) {
    req, err := http.NewRequest("GET",
        "https://profile.internal/users/"+userID,
        nil,
    )
    if err != nil {
        return nil, err
    }

    req = req.WithContext(ctx)
    return http.DefaultClient.Do(req)
}

后台 goroutine 要主动接收退出信号

如果业务代码里为了加速并发手动启动了 goroutine，这里要格外留意。goroutine 一旦启动，绝对不会因为 handler 执行完返回就自动消失。它需要在 select 逻辑里监听 ctx.Done()，或者从上层收到明确的关闭通知通道。

func startWorker(ctx context.Context, jobs 

第二个 select 很多人都容易漏掉。不少 goroutine 泄漏的问题都不是出在取任务的环节，而是出在把结果写回 channel 的步骤上。用户已经离开，handler 不会再读 out 里的数据，worker 逻辑如果还在往 channel 里硬写结果，就会一直卡在那里无法退出。

超时、取消和错误返回的区别

实际业务逻辑里，取消和超时最终都表现为 ctx.Err() 不为空，但两者的实际含义不一样。用户主动断开连接，通常属于主动取消场景；服务端设置的耗时预算耗尽，则属于超时场景。日志记录和后续的响应策略可以分开做差异化处理。

做这个区分很有必要。如果把所有用户主动取消的场景都打成错误日志，会产生大量无用告警干扰排查；反过来把所有超时都当成用户主动取消，又会掩盖慢查询和下游服务抖动的真实问题。

接口体验上要提前考虑边界状态

这部分虽然偏业务场景，但对 Go 开发者来说也很实用：用户点了取消、刷新页面或者网络断开之后，服务端应该尽快收尾释放资源；但如果任务逻辑已经进入不可中断的外部系统，比如支付已经提交、消息已经投递完成、文件已经写入存储，就不能假装所有操作都可以撤回。

更推荐把接口分成两类来做差异化处理：

• 查询、预览、搜索、导出预估这类可重试的操作：完全跟随请求 context 的取消逻辑，用户离开就尽快停止后续逻辑。
• 支付、下单、扣库存、发送消息这类有副作用的操作：前台请求的取消可以响应，但后台必须用幂等键、任务状态机和补偿逻辑来保证最终结果可追踪。
• 长耗时导出、批量数据处理这类重逻辑：不要直接绑定在一次 HTTP 请求的生命周期上，建议直接返回任务 ID，后续用户再通过独立的查询接口获取任务状态。

相关问题

r.Context() 什么时候会被取消？

常见触发场景包括客户端连接断开、请求处理流程结束、HTTP/2 请求被主动取消，或者上层服务主动触发取消操作。至于取消信号能不能及时传到下游逻辑，完全看你的调用链有没有全程复用同一个 context 实例。

context 取消会直接杀掉 goroutine 吗？

不会。context 只是传递通知信号的载体，不是强制终止进程的工具。goroutine 必须主动监听 ctx.Done() 的关闭事件，收到信号后自己执行返回逻辑。

每个接口都要手动加 context.WithTimeout 吗？

涉及 IO 操作、访问数据库或者调用下游服务的接口，确实应该加上超时控制。纯内存计算、耗时极短的本地逻辑可以不用额外包超时，但整个服务层面依然要有清晰的全链路超时边界。

超时触发之后还能继续往客户端写响应吗？

不建议依赖这种行为。请求上下文已经被取消时，客户端大概率已经不再接收响应数据了。这时候代码应该优先停止正在执行的工作、释放占用的资源，把关键状态落到日志或者任务记录里即可。

小结

Go HTTP 请求取消后的核心逻辑其实很清晰：取消信号会从 r.Context() 发出来，但后台任务会不会真的停止，完全取决于你有没有把 context 透传到真正发生等待的地方。数据库操作全部用带 context 的方法，下游 HTTP 请求全程传递 WithContext，手动启动的 goroutine 主动监听 ctx.Done()，再配合服务端自身的超时预算和副作用边界处理，就能做到用户离开之后，服务端的资源也能干干净净及时释放。