Gin框架数据库操作应选parent context/gin.Context/gin.Request.Context？

核心结论 #

优先使用请求自带的c.Request.Context()，不建议继续使用自定义传入的parentContext，也不建议直接将*gin.Context传递给DB、RPC等底层方法。 #

具体原因 #

• Gin的请求Context默认绑定了请求生命周期的取消信号：客户端主动断开、网关超时、请求处理超时触发时，c.Request.Context()会自动发送取消通知，下游的IO类操作（DB查询、远程调用等）可以监听到信号直接终止，避免无效资源占用。你自定义传入的parentContext通常是服务根Context，只有服务关停时才会触发取消，完全覆盖不到请求维度的中断场景，很容易出现goroutine泄漏。
• 直接把*gin.Context传给底层方法会带来不必要的框架耦合：业务逻辑、数据访问层不需要依赖Gin的类型定义，后续如果要更换Web框架、或者把逻辑抽离出来给CLI、GRPC服务复用，会需要大量修改入参，维护成本极高。
• 如果你的parentContext里存储了全局链路追踪、服务元数据等通用信息，可以通过中间件把对应KV值合并到请求Context中，后续所有逻辑直接取c.Request.Context()就能拿到全部需要的元信息，不需要再单独维护parentContext的传递链路。

参考实现 #

// 中间件：合并全局parentContext的自定义值到请求Context
func MergeGlobalContext(parentCtx context.Context) gin.HandlerFunc {
    return func(c *gin.Context) {
        // 此处可以自定义复制逻辑，把parentCtx中需要的KV、链路信息复制到请求Context
        mergedCtx := mergeContext(parentCtx, c.Request.Context())
        // 替换原有请求的Context
        c.Request = c.Request.WithContext(mergedCtx)
        c.Next()
    }
}

// HTTP处理器逻辑
func DemoHandler(c *gin.Context) {
    // 直接使用请求Context传递给下游方法即可
    data, err := db.Query(c.Request.Context(), "SELECT * FROM demo WHERE id = ?", 1)
    if err != nil {
        // 错误处理逻辑
        c.JSON(500, gin.H{"error": err.Error()})
        return
    }
    c.JSON(200, data)
}

特殊场景说明 #

• 如果需要给单个请求的下游操作设置独立超时，可以基于c.Request.Context()再封装一层带超时的Context使用，不需要依赖外部parentContext。
• 不要在*gin.Context中存储业务自定义KV，所有链路通用元数据统一存入标准库context.Context，保证跨框架、跨调用场景的兼容性。

内容的提问来源于stack exchange，提问作者Ihsan Müjdeci