Go Gin框架context.Done()未按预期工作 无法取消请求处理协程

代码无法触发取消逻辑是三个核心问题导致的：

• time.Sleep 是同步阻塞调用，10秒等待期间goroutine会完全卡住，根本不会执行到后续的select分支监听逻辑，就算客户端已经断开连接，也要等sleep全部执行完才会检查Done信号，自然无法及时退出。
• c.Copy() 拷贝生成的Gin上下文，设计目标就是供脱离请求生命周期的异步逻辑安全使用，不会继承原请求的Context取消链路，在子goroutine里监听cCp.Done()本来就收不到原请求的断开事件。
• c.Done()和c.Request.Context().Done()的触发前提是Go HTTP服务感知到客户端连接断开，如果服务前挂了反向代理且没有配置断连透传，或者本地测试时浏览器存在连接复用行为，可能会出现感知延迟，但代码写法问题是失效的核心原因，和Go、Gin版本无关。

先明确两个核心原则：

1. 不要用c.Copy()生成的上下文监听请求取消，直接使用原请求的c.Request.Context()，这个是标准库net/http维护的、绑定请求全生命周期的上下文，客户端断开时会主动触发取消信号。
2. 长耗时等待逻辑不要裸用time.Sleep阻塞，要把等待、任务执行逻辑和取消信号放在同一个select块中监听，保证取消信号到达时能立刻响应。

修正后的可运行代码如下：

respChan := make(chan types.Result)
defer close(respChan)

// 直接取原请求的上下文，绑定当前请求生命周期
reqCtx := c.Request.Context()

go func() {
    for {
        fmt.Println("check")
        test := []types.ResultTXT{{Txt: "Test Resp"}}

        // 用定时器替代裸time.Sleep，和取消信号一起监听
        taskTimer := time.NewTimer(10 * time.Second)
        select {
        case <-reqCtx.Done():
            fmt.Println("goroutine canceled")
            taskTimer.Stop()
            return
        case <-taskTimer.C:
            // 此处放置单轮长耗时任务逻辑
        }

        select {
        case <-reqCtx.Done():
            fmt.Println("goroutine canceled")
            return
        case respChan <- types.Result{Response: test}:
            fmt.Println("Work end")
            return
        }
    }
}()

select {
case <-c.Done():
    fmt.Println("request canceled by client")
    c.Abort()
    return
case res := <-respChan:
    result := res.Response
    c.HTML(http.StatusOK, "response.html", gin.H{
        "Resp": result,
    })
    return
}

• 本地直连Gin服务测试时，主动关闭标签页、点击页面刷新基本可以立刻触发取消逻辑；如果服务前部署了Nginx等反向代理，需要开启代理在客户端断开时主动关闭上游连接的配置，否则Gin无法感知到客户端的断连行为。
• c.Copy()的使用场景是异步逻辑需要读取原请求的元数据（比如请求头、用户ID等），不要用它来做取消监听；同时Gin原始上下文c不是并发安全的，禁止在子goroutine中直接用c写响应、修改字段，避免数据竞争。
• 如果长耗时逻辑是数据库查询、RPC调用这类IO操作，需要将reqCtx作为参数传入对应调用方法，让下游操作也能同步感知取消，避免无效的资源消耗。

内容的提问来源于stack exchange，提问作者regiment