Gin框架监听Context主动取消-Golang-PHP中文网

gin不会自动传播context取消信号，需手动监听ctx.done()并清理资源；http/1.1断连延迟触发，必须用select响应取消以立即终止阻塞操作。

gin框架监听context主动取消

Context取消信号没被gin路由函数捕获？

Gin 默认把 context.WithTimeout 或 context.WithCancel 创建的子 Context 传给 handler，但你手动调用 cancel() 后，handler 里 ctx.Done() 可能迟迟不触发 —— 根本原因是 Gin 的底层 http.Server 没有把连接关闭事件映射到 Context 的 cancel 函数上，得靠你自己桥接。

典型表现：用户关掉页面或中断请求，ctx.Err() 还是 nil，goroutine 卡在数据库查询或 HTTP 调用里不退出。

必须显式监听 ctx.Done() 并做清理，不能只靠 defer
Gin 不会自动 propagate cancel；它只负责把 *http.Request.Context() 透传进来
HTTP/1.1 下断连可能延迟几百毫秒才触发 ctx.Done()，HTTP/2 更快但仍有窗口期

在 handler 中正确响应 Context 取消

别等超时或靠轮询，直接用 select 监听 ctx.Done()，并在分支里释放资源。重点不是“有没有取消”，而是“取消后是否立刻停掉阻塞操作”。

Gin框架 1.9.0

Gin框架 1.9.0版本源码包下载，版本号 1.9.0，适合需要 sonic JSON 支持、路由修复和内容协商改进的 Go Web 开发场景。

下载

func handleData(ctx *gin.Context) {
    // 假设这里要调一个可能慢的外部服务
    req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com/data", nil)
    
    select {
    case

所有阻塞调用（http.Client.Do、db.QueryRowContext、time.Sleep）都应配合 ctx 使用
http.NewRequestWithContext 是必须的，裸用 http.NewRequest 会丢失 cancel 信号
不要在 select 外写业务逻辑，否则取消来临时仍会执行完当前语句

中间件里统一注入可取消 Context（带超时）

手动在每个 handler 里写 context.WithTimeout 易遗漏。用中间件统一封装，同时避免超时时间硬编码。

func TimeoutMiddleware(timeout time.Duration) gin.HandlerFunc {
    return func(c *gin.Context) {
        ctx, cancel := context.WithTimeout(c.Request.Context(), timeout)
        defer cancel() // 注意：这里 defer 是安全的，因为 cancel 只影响后续阻塞操作
        
        c.Request = c.Request.WithContext(ctx)
        c.Next()
    }
}

务必用 c.Request.WithContext() 替换原 request，否则下游 handler 拿到的还是原始 Context
defer cancel() 没问题，但 cancel 本身不阻塞，真正起效的是之前传入的 ctx 被监听
超时值建议从配置读取，比如 viper.GetDuration("http.timeout")，避免写死
这个中间件要放在 gin.Recovery() 之后、业务 handler 之前

客户端主动断连时的边界情况

浏览器刷新、F5、关闭 tab，甚至 curl -v 加 Ctrl+C，都可能让服务端收到 FIN 包。但 Go 的 net/http 不会立即通知，而是在下一次 read/write 时返回 error，并最终触发 ctx.Done()。所以“立刻响应取消”本质是依赖 I/O 调用是否支持 Context。